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ABSTRACT 

This  thesis  explores  the  feasibility  of  developing  a 
tactical  display  simulator  on  the  H/Z-100  microcomputer.  A 
prototype  simulator  is  implemented  in  ZBASIC,  some  graphics 
functions  routines  are  implemented  in  Macro-86,  and  timing 
and  performance  measurements  are  performed  for  comparison. 

Listings  of  the  programs  developed  are  presented,  as 
well  as  instructions  for  their  effective  use.  Directions 
for  the  modification  of  the  code,  and  suggested  profitable 
areas  of  exploration  and  further  development  are  included. 

It  is  concluded  that  a  tactical  display  simulator  is 
feasible,  and  that  the  final  implementation  should  be  in 
Macro-86 . 
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I.   INTRODUCTION 

A.   BACKGROUND 

The  Naval  Postgraduate  School  has  arranged  to  purchase 
approximately  fifty  Zenith  H/Z-100  microcomputers  for  the 
microcomputer  laboratories  of  the  Computer  Science  Depart- 
ment. There  were  numerous  reasons  for  that  particular 
microcomputer  to  be  chosen,  one  of  which  is  the  fact  that 
it  possesses  a  dual  micro-processor  architecture  [Ref.  1: 
p.  E.l].  It  has  the  8085,  an  8-bit  microprocessor,  which 
is  typical  of  a  simple  architecture  and  instruction  set, 
and  able  to  run  software  under  the  CP/M  operating  system. 
It  uses  a  simple,  single-segment  model  of  memory.  The 
H/Z-100  also  comes  equipped  with  the  newer  and  more 
powerful  8086,  a  16-bit  microprocessor,  with  an  eight  bit 
memory  interface.  It  makes  use  of  a  more  complex 
architecture,  more  internal  registers  (some  useable  as  8- 
or  16-bit),  extended  addressing  modes,  and  a  more  complex 
memory  management  scheme,  with  segmentation  registers. 

Another  attractive  feature  of  the  H/Z-100  is  its 
graphics  capability.  In  the  character  display  mode,  the 
H/Z-100  can  display  25  rows  of  80  characters.  A  very 
important  graphics  ability  is  the  degree  of  resolution 
provided.  The  H/Z-100  provides  high-resolution  dot 
addressability,   with   a   dot   resolution  of  640  horizontal 
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dots  by  225  vertical  dots.  In  the  interlace  mode,  the  H/Z- 
100  provides  640  x  512  pixels.  It  also  comes  equipped 
with  three  64K  pages  of  video  RAM  memory,  eight  colors  in 
the  color  option  with  a  color  monitor,  or  eight  grey  scale 
levels  with  the  color  option  and  a  monochrome  monitor  , 
light  pen  circuitry,  and  the  potential  for  two  pages  of 
video  display  to  be  stored  simultaneously . [Ref.  1:  p. 
E.2]  As  a  natural  consequence  of  this  purchase,  the 
micro-computer  laboratory  is  interested  in  developing  a 
variety  of  special-purpose  software  products  to  maximize 
the  value  of  these  computers.  A  primary  use  for  these 
software  products  will  be  in  courses  which  emphasize 
tactical  applications  of  computers.  Graphical  displays  are 
a  vital  and  integral  part  of  tactical  applications. 
Software  products  which  provide  graphical  support  for 
tactical  applications  and  demonstrations  of  interactive 
graphical  displays  that  enhance  tactical  decision-making  is 
very 
desirable. 

B.   OPERATING  SYSTEM  SUPP.ORT 

The  operating  system  provided  with  the  H/Z-100 
computers  purchased  by  the  Naval  Postgraduate  School  (NPS) 
is  the  Microsoft  Disk  Operating  System.  It  is  our  opinion 
that  the  MS-DOS  operating  system  is  a  powerful  and 
practical  one.  It  provides  the  user  with  54  commands,  27 
resident  commands  and  27  transient  commands  [Ref.  2:  pp. 
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9.2-5.4].  Several  of  these  commands  are  useful  tools  for 
the  software  developer. 

There  is  a  deficiency  in  the  MS-DOS  operating  system, 
however,  related  to  graphics-oriented  applications.  There 
is  virtually  no  operating  system  support  of  graphics 
functions  provided  by  MS-DOS,  the  one  exception  being  the 
CLS  (clear  screen)  command  [Ref.  2:  p.  5.2]. 

There  is  a  crucial  need  for  graphics  function  support 
of  tactical  applications  involving  real-time  displays.  The 
system  is  required  to  provide  a  current  graphical  display 
of  the  tactical  situation  at  the  same  time  that  changes  in 
that  tactical  situation  are  being  evaluated.  Computations 
of  the  time-dependent  tactical  elements,  display  of  the 
current  situation  and  acceptance  of  user  inputs  to  the 
system  must  be  performed  simultaneously,  or  nearly  so.  The 
tactical  display,  which  may  be  changing  rapidly  in  the  case 
of  high-speed  targets  such  as  missiles  and  slowly  where 
stationary  and  slow-moving  tactical  units  are  concerned, 
must  be  updated  with  a  minimum  frequency  of  once  per  second 
to  be  useful.  This  requirement  generates  the  need  for 
effective,  special  purpose,  time  efficient  code. 

C.   PURPOSE 

We  propose,  as  an  initial  system  development  project  to 
meet  the  purposes  stated  above,  the  development  of  a  Naval 
Tactical  Data  System  (NTDS)  display  simulator,  to  be 
implemented   on   the   H/Z-100   microcomputer.       A  rapid 
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prototype  of  a  display  simulator  will  be  developed,  to 
provide  guidelines  for  developing  graphics  support  tools 
for  tactical  systems  applications  such  as  those  mentioned 
earlier.  The  systematic  approach  used  in  developing  this 
prototype  will  demonstrate  many  of  the  considerations  that 
graphics  support  tools  must  entail.  The  displays  this 
prototype  provides  will  be  illustrative  of  typical  tactical 
displays  that  these  applications  require.  Portions  of  the 
prototype  will  be  transferred  into  more  time  efficient 
code,  in  order  to  ascertain  the  order  of  magnitude  of 
efficiency  gain  that  may  be  expected  and  to  demonstrate  the 
transfer  process. 

The  development  of  an  entire  NTDS  display  simulator  is 
a  major  undertaking.  Although  it  sounds  good  as  a  concept, 
the  logical  first  step  would  be  a  preliminary  feasibility 
study.  This  study  will  be  an  initial  look  at  the 
feasibility  of  developing  an  NTDS  display  simulator  on  the 
H/Z-100.  We  will  be  attempting  to  ascertain  that 
feasibility  by  exploring  algorithms  necessary  to  support 
the  graphics  sub-system  of  such  a  system,  since  graphic 
display  is  an  integral  part  of  the  system  being  simulated 
and  will  largely  determine  the  real-time  aspects  of  the 
system.  We  will  develop  code  for  portions  of  the  graphic 
display  subsystem,  and  perform  some  performance  tests  on 
that  code.  We  intend  and  hope  for  this  to  be  the  basis  for 
the  development  of  a  graphics  system  which  permits  NTDS 
display  subsystem  simulation. 
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D.   THESIS  ORGANIZATION 

In  Chapter  II  we  present  algorithms  devel  ped  for  this 
initial  project.  We  describe  the  symbol  generator 
subsystem  algorithm  in  detail.  Design  focuses  primarily  on 
the  symbol  generator  itself.  We  also  provide  some  of  the 
design  considerations  made,  brief  explanations  of  reasons 
for  specific  choices,  and  discuss  some  ramifications  of 
alternatives.  Algorithms  employed  to  develop  sample  NTDS- 
type  displays  are  also  presented  here. 

Chapter  III  describes  the  code  developed  and  debugged 
to  date  for  the  display  simulator.  We  have  a  successful 
prototype  implemented  in  ZBASIC  and  some  initial  routines 
for  graphics  support  in  Macro-86  assembler  language. 

The  next  chapter,  Chapter  IV,  is  devoted  to  efficiency 
issues.  Much  of  the  code  provided  in  the  Appendixes  has 
sacrificed  efficiency  for  clarity.  .  We  felt  that,  in  a 
ground-breaking  project  such  as  this  one,  the  use  of  easily 
traceable  logic  in  the  code  was  more  valuable  than  the  use 
of  tricky  code  which  might  execute  more  rapidly.  Initial 
performance  tests  and  timing  runs  are  summarized. 

The  final  chapter,  Chapter  V,  provides  suggestions  for 
the  most  effective  use  of  what  has  been  done  to  date.  It 
also  suggests  some  of  the  potential  future  directions  for 
follow-on  work.  That  is  where  the  conclusions  of  this  work 
are  presented.  The  focus  is  on  what  has  been  learned  that 
may  be  of  value  to  other  students  and  researchers. 
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Appendixes  A-M  are  listings  of  the  ZBASIC  programs 
developed  to  date  as  a  working  prototype  of  the  NTDS 
display  simulator.  A  User's  Manual  which  gives  a  line-by- 
line description  of  the  programs  in  Appendixes  A-M,  and 
important  considerations  when  modifying  the  code,  is 
contained  in  Appendix  N.  Listings  of  Macro-86  programs  are 
in  Appendixes  0-U.  Appendix  V  is  a  User's  Manual  for  the 
code  in  those  Appendixes. 
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II.   ALGORITHMS 

A.   BASIC  SIMULATOR  ALGORITHM 

To  perform  the  functions  of  an  NTDS  display  simulator, 
we  must  implement  an  algorithm  similar  to  that  in  Figure 
2.1.  The  initialization  depends  somewhat  on  the 
implementation  chosen.  The  display  simulator  requires  that 
some  basic  items  be  displayed  as  a  minimum,  such  as  a 
working  area  on  the  screen  (window),  a  reference  grid, 
possibly  some  land  or  other  special  areas  within  the  window 
and  basic  symbols.  A  more  detailed  explanation  of  what  is 
displayed  in  our  prototype  is  contained  in  the  next  chapter 
on  code. 


begin 

initialize  display,  system 
repeat 

repeat 

delay 

update  all  tracks 
until  (there  is  a  user  service  request) 
perform  service  requested 
until  (user  requests  exit) 
end 

Figure  2.1   Basic  Simulator  Algorithm 


The  user  service  requests  are  also  defined  by  the  NTDS 
environment.  We  have  chosen  six  NTDS-type  user  functions 
to  implement,  two  of  which  are  related  to  use  of  this 
simulator.  Other  functions  may  be  added  to  the  simulator 
easily   enough,  as  explained  in  the  code  chapter.   They  are 
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not  limited  by  those  required  by  the  simulation.  The 
system,  particularly  as  a  graphics  subsystem,  is  eventually 
able  to  support  multiple  purposes,  including  services  that 
are  not  NTDS  related.  The  services  implemented  in  the 
prototype  are  a  sampling  of  services,  and  are  not  meant  to 
be  exhaustive. 

B.   EXPANDED  SYSTEM  ALGORITHM 

The  basic  algorithm  has  been  expanded  through  a  series 
of  step-wise  refinements  to  the  algorithm  shown  in  Figure 
2.2.  The  intervening  steps  are  not  included  as  they  would 
not  provide  sufficient  information  that  is  not  contained  in 
the  final  version  to  warrant  inclusion. 

In  some  statements  greater  detail  than  is  normally 
associated  with  algorithmic  language  has  been  brought 
forward  to  the  algorithm  itself  and  its  explanation.  This 
is  to  begin  to  acquaint  the  reader  with  the  prototype. 
Some  sections  of  the  algorithm,  whether  they  are 
represented  as  single  or  multiple  statements  in  Figure  2.2, 
are  expanded  even  further,  where  clarification  was  felt  to 
be  necessary  or  desired.  Where  greater  expansion  has  been 
provided  it  is  the  aim  of  the  author  to  provide  insight 
in  o  the  decision-making  process  during  the  design  of  such 
a  prototype  system.  There  has  been  more  effort  expended  in 
attempting  to  provide  clear  logic  in  the  algorithms  and 
code  presented  than  in  driving  for  efficiency. 
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begin 

clear  screen 

initialize  variables,  tracks 

display  function  key  menu 

read  (window  parameters) 

display  window 

read  (#  of  land  masses  to  display) 

if  (#  of  land  masses  >  0)  then 

display  land  masses 
read  (Y-axis  parameters,  X-axis  parameters) 
display  coordinate  axes 
read  (#  of  tracks) 
if  (#  of  tracks  >  0)  then 
begin 

for  (#  tracks)  times 
begin 

read  (current  track  parameters) 
look-up  symbol  to  match  parameters 
make  track  active 

calculate  incremental  movement  of  track 
look-up  speed  leader  to  match  parameters 
end 
end 
repeat 

while  (no  user  input) 
begin 

update  all  tracks 
delay 
end  while 

if  (user  input  is  a  function  key)  then 
do  indicated  function 
until  (user  input  =  halt) 


end 


Figure  2.2   Expanded  System  Algorithm 
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1 .   Expansion  of  "Display  Land  Masses" 

Figure  2.3  is  an  expansion  of  the  "display  land 
masses"  statement  of  the  Expanded  System  Algorithm.  It  is 
shown  because  the  lack  of  true  dynamic  memory  allocation  in 
the  prototype  created  special  problems.  This  algorithm 
expansion  illustrates  one  type  of  solution  to  those 
problems.  The  problem  is  one  that  will  not  be  evident  in 
the  programming  language  which  will  be  used  in  the  future 
to  fully  develop  the  graphics  system.  We  accepted  the 
problem  here,  and  dealt  with  it  in  this  manner,  in  order  to 
develop  the  rapid  prototype. 

In  this  prototype  we  provide  for  three  land  masses. 
The  elements  of  the  PTS  array  must  be  initialized,  because 
they  are  used  to  determine  the  amount  of  memory  to  allocate 
for  the  land  mass  arrays.  As  a  consequence,  multiple 
iterative  loops  are  contained  in  the  algorithm.  Because 
they  are  pre-initialized,  the  elements  of  the  PTS  array  are 
used  as  flags  to  indicate  when  to  stop  drawing  land  masses. 
The  lower  bound  of  two  was  selected  to  allow  this  module  to 
draw  even  tiny  representations  on  the  display. 

This  is  an  example  of  a  design  decision  point. 
There  are  other  ways  that  the  lack  of  dynamic  memory 
allocation  could  have  been  handled.  This  is  not  the  most 
efficient  choice,  but  it  presents  uncomplicated  logic.  The 
data  in  this  solution  establishes  a  pattern.  The  number  of 
points  and  color  for  the   maximum  number  of  land  masses  the 
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begin 


for  (#  land  masses)  times 

read  (PTS,  LCOL)    (#  points,  color  for 


for  (PTS(l))  times 
read  (X,  Y) 

for  (PTS(2))  times 
read  (X,  Y) 

for  (PTS(3))  times 
read  (X,  Y) 

draw  LAND1 

read  (CENTX,  CENTY) 

paint  LAND1 


each  land  mass  ) 
(  points  for  LAND1  ) 

(  points  for  LAND2  ) 

(  points  for  LAND3  ) 

(  interior  pt .  ) 


if  (PTS(2))  >=  2  then    (if  there  is  LAND2) 
begin 

draw  LAND2 

read  (CENTX,  CENTY) 

paint  LAND2 
end 
else  end 

if  (PTS(3))  >=  2  then    (if  there  is  LAND3) 
begin 

draw  LAND3 

read  (CENTX,  CENTY) 

paint  LAND3 
end 


end 


Figure  2.3   Display  Land  Algorithm 
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system  will  handle  must  be  provided  as  data,  in  order  to 
allow  dimensioning  of  arrays.  Since  a  number  of  points  for 
any  dummy  land  (one  point)  is  required  in  the  data,  this 
solution  requires  that  each  dummy  land  mass  have  that  one 
point  in  the  data.  This  also  ensures  that  a  user  who 
wishes  to  modify  one  data  file  rather  than  generate  a  new 
one  has  created  space  in  the  data  module  for  the  added 
land  masses. 

We  note  again  that  these  are  problems  that  will  be 
nonexistent  in  Ada,  as  well  as  in  Macro-86  graphics 
functions.  They  result  from  the  use  of  ZBASIC  in  this 
prototype,  which  was  selected  simply  for  the  rapidity  with 
which  a  working  demonstration  of  the  display  simulator 
could  be  developed.  This  provides  early  feasibility 
determination,  guidelines  for  future  development,  and 
demonstrates  graphics  concerns. 

2.   Expansion  of  "Display  Coordinate  Axes" 

This  algorithmic  step  is  expanded  for  those  who 
have  little  or  no  computer  graphics  background.  The  simple 
algorithm  shown  in  Figure  2.4  deals  with  the  problem  of 
maintaining  the  proper  aspect  ratio  between  the  horizontal 
and  vertical  axis  scales.  It  is  based  on  a  program  cited 
in   the   code   and  written  by  James  C.  Adams  [Ref.  3:  p.  9- 

15]. 

The  aspect  ratio  in  computer  graphics  is  the  ratio 
of   horizontal   to   vertical   on   the  display.   The  H/Z-100 
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monitor  provides  640  pixels  in  the  horizontal  direction  and 
225  pixels  in  the  vertical  direction  [Ref.  2:  p.  E.l].  In 
order  for  the  scale  divisions  on  the  two  axes  to  appear 
equal  they  must  have  different  pixel  spacing. 


begin 

calculate  horizontal  scale 

calculate  vertical  scale 

draw  vertical  axis 

draw  horizontal  axis 

draw  horizontal  scale  divisions 

draw  vertical  scale  divisions 

end 


Figure  2.4   Display  Axes  Algorithm 

3.   Expansion  of  "Do  Indicated  Function" 

The  "do  indicated  function"  is  expanded  because  it 
is  a  case  statement.  That  fact  is  not  evident  by  looking 
at  the  code,  since  it  is  written  in  a  language  that  does 
not  provide  a  case  statement  construct. 

We  considered  only  partially  expanding  this  section 
of  the  system  algorithm.  Case  statements  are  widely  under- 
stood, and  tend  to  become  repetitive.  Since  one  of  the 
concerns  of  this  project  is  to  provide  development  history, 
and  another  is  to  document  some  decision  process  in 
practice,  we  elected  to  fully  expand  it.  The  full  expan- 
sion is  illustrated  in  Figure  2.5. 
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begin 

case  function  of: 
begin 

halt:   begin 

clear  screen 
restore  function  keys 
exit  system 
end 
suspend/continue: 
begin 

wait  for  user  input 
end 
hook  track: 
begin 

if  (some  track  hooked)  then 

unhook  track 
read  (track  to  hook) 
hook  track 
end 
enter  track: 
begin 

read  (track  parameters) 
calculate  track  movement 
look-up  speed  leader,  symbol 
display  track 
end 
modify  track: 
begin 

if  (some  track  hooked)  then 

unhook  track 
read  (track  to  modify 
hook  track 

for  (each  track  field) 
begin 

ask  user  if  OK 
if  not  OK  then 
make  change 
end 
end 
delete  track: 
begin 

read  (track  to  delete) 
make  track  inactive 
end 
end  (case) 


Figure  2.5   Do  Indicated  Function  Algorithm 
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C.   CONCLUSION 

These  algorithms  are  simply  the  rough-hewn  blueprints 
for  producing  the  prototype  display  simulator.  Comparing 
them  with  the  code  in  Appendices  A-M  discloses  some  of  the 
design  choices  which  had  to  be  made  during  implementation. 
Inspection  of  the  algorithms  alone  reveals  some  of  the  pre- 
thinking  that  they  embody.  Knowing  the  capabilities  and 
limitations  of  the  target  system  and  the  programming  lan- 
guage influenced  the  construction  of  the  algorithms.  In 
some  instances  that  was  beneficial,  in  others  less  so. 

Algorithms  could  have  been  shown  for  each  module  of  the 
working  prototype,  no  matter  how  trivial.  This  would  have 
served  no  useful  purpose.  The  important  design  lesson  here 
is  that  the  more  carefully  the  algorithm  was  developed  and 
thought  out  before  the  module  was  coded  the  more  rapidly 
the  coding  was  successfully  carried  out. 
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III.   CODE 

A.   LANGUAGE 

An  early  concern  in  any  software  development  is  the 
choice  of  a  programming  language.  There  are  a  plethora  of 
languages  and  language  subsets  to  choose  from.  Many  times 
the  choice  is  heavily  dependent  on  the  experience  and 
preferences  of  the  programmer ( s )  and  the  availability  of  the 
preferred  language  on  the  target  machine.  These  dependen- 
cies may  narrow  the  choices  but  do  not  define  absolutely  the 
language  to  use  in  most  cases. 

This  NTDS  display  simulator  is  no  exception  to  the 
considerations  listed  above.  The  development  phase  of  a  new 
piece  of  software  is  not  the  best  of  times  to  attempt  to 
learn  a  new  language.  Therefore  only  languages  familiar  to 
us  were  considered.  The  H/Z-100  computers  that  NPS  is  pur- 
chasing will  not  come  with  software  support  for  all  cur- 
rently existing  programming  languages.  They  are  capable  of 
using  languages  which  possess  most  of  the  currently 
available  language  features. 

The  driving  consideration  in  many  projects,  certainly 
one  of  the  most  important  issues  if  not  the  most,  is  the 
project  itself.  Each  language  has  features  which  are  better 
for  some  applications  and  suffer  inefficiency  (or  even 
impotence)  for  others.  For  the  display  simulator  the  two 
critical   issues   are   graphics  support  and  speed.   The  more 
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graphics  support  the  language  provides,  the  more  rapidly  a 
prototype  may  be  implemented  and  tested.  The  more  efficient 
the  language  in  terms  of  processing  speed  the  better  it  is 
able  to  approach  real-time  updates  of  the  display  and  its 
symbology . 

We  feel  that  Macro-86  assembly  language  offers  the  most 
real-time  capability.  If  the  NTDS  display  simulator  were 
written  in  assembly  language,  it  would  probably  meet  or 
exceed  the  time  requirements  to  provide  realistic,  dynamic 
displays.  Macro-86  maximizes  the  utilization  of  the  power 
of  the  H/Z-100  computer  through  segmentation  and  paging,  as 
well  as  allowing  direct  access  to  the  color  planes  for  video 
control. 

Macro-86  assembly  language  also  offers  a  wide  range  of 
interfaces  with  high-level  languages.  In  particular  we  are 
interested  in  Ada,  which  is  available  for  the  H/Z-100  and 
which  is  playing  an  ever-increasing  role  in  Department  of 
Defense  applications.  Ada  has  the  ability  to  make  use  of 
Macro-86  routines.  This  would  allow  Ada  packages  to  be 
written  for  numerous  applications,  making  use  of  Macro-86 
routines  which  provide  basic  graphics  functions. 

Macro-86  assembly  language  does  not  provide  direct 
support  for  the  graphics  functions  the  display  simulator 
needs.  Even  direct  input  and  output  requires  special 
handling,  register  control,  and  several  lines  of  code. 
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The  considerations  above  led  us  to  choose  ZBASIC  for  an 
initial  prototype  implementation,  and  Macro-86  for  ultimate 
development  and  production.  We  felt  that  a  working 
prototype  could  be  developed  in  considerably  less  time  in 
ZBASIC  (in  fact,  a  prototype  of  the  graphics  display 
subsystem  has  been  completed  and  is  included)  and  used  for 
experimentation,  testing  and  further  enhancement.  We  did 
develop  some  basic  Macro-86  routines  for  graphics  support  of 
the  simulator  and  testing,  and  they  are  included.  The  major 
drawback  of  ZBASIC  for  further  development  is  its  lack  of 
compatibility  with  other  high-level  languages. 

B.   DATA  STRUCTURES 

It  may  help  to  visualize  each  track  in  this  system  as  a 
record  of  the  type  illustrated  in  Figure  3.1.  ZBASIC  does 
not  provide  data  structures  which  are  composed  of  fields 
with  different  types.  A  separate  array,  therefore,  repre- 
sents each  field  of  the  TRACK  record. 

The  other  arrays  are  used  as  look-up  tables  for  various 
attributes.  The  type  of  symbol  assigned  to  a  track  is  found 
in  the  array  SYM$,  the  speed  leaders  are  in  LDR$ ,  the  number 
of  points  determining  a  land  mass(up  to  three  land  masses 
are  provided  for)  are  found  in  PTS  with  each  corresponding 
land  mass  color  in  LCOL.  These  tables  (SYM$  and  LDR$)  are 
initialized  in  lines  180-440  (see  Appendix  A). 
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There  are  provisions  for  ten  pre-defined  symbols,  and 
seven  symbols  are  defined  in  this  prototype.  By  changing 
the  dimension  of  SYM$  and  its  initialization,  any  number  of 
symbols  (up  to  memory  limitations)  are  defineable.  Changes 
to  the  symbols  should  be  accompanied  by  changes  to  the  Match 
module,  which  assigns  symbols  to  tracks  based  on  their 
CLASS$.  The  dimension  of  CLASS$  would  not  be  changed — its 
dimension,  along  with  that  of  the  other  fields  of  each  TRACK 
record  (see  Figure  3.1),  determine  the  number  of  tracks  the 
system  will  accommodate.  These  are  some  of  the  problems 
inherent  in  a  ZBASIC  rapid  prototype  which  will  disappear 
with  Ada  packages,  and/or  Macro-86  implementation  of  the 
display  simulator  functions. 


type  TRACK  = 

CLASS$ 

CUS 

SPD 

TCOLOR 

TX 

TY 

XINC 

YINC 

T$ 

L$ 

HK$ 

ACTIVE 
end;  (TRACK) 


record 
array  [1..9]  of  char; 
integer; 
integer; 
integer ; 
integer ; 
integer ; 
integer ; 
integer ; 

array  [1..80]  of  char; 
array  [1..2]  of  char; 
array  [1..2]  of  char; 
integer; 


class ) 
course) 
speed) 
color) 
x  position) 
y  position) 
x  increment) 
y  increment) 
symbol ) 
speed  leader) 
scale) 
active/ref  pt) 


Figure  3.1   TRACK  Record  Structure 

There  are  eight  pre-defined  speed  leaders,  which 
correspond  to  the  four  cardinal  and  four  inter-cardinal 
directions.   This,  too,  could  be  modified,  with  changes  here 
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and  in  the  Move  module,  which  assigns  speed  leaders  to  each 
TRACK  based  on  course  and  speed. 

The  string  construction  of  the  elements  of  the  SYM$  and 
the  LDR$  arrays  makes  use  of  a  "language  within  a  language" 
that  Z3ASIC  provides  for  graphics  applications.  This 
language  is  the  Microsoft  "Graphics  Macro  Language"  (GML) . 
[Ref.  3:  p.  5.5] 

There  is  no  provision  for  subtypes  in  the  ZBASIC  lan- 
guage. For  that  reason  some  of  the  fields  of  the  TRACK 
structure  may  inadvertently  be  assigned  meaningless  values. 
In  some  cases  that  will  result  in  program  termination  and 
the  display  of  an  error  message  by  the  interpreter.  In 
other  cases  it  may  result  in  undesirable  side  effects,  or 
unexpected  displays.  Subtypes  could  have  been  enforced  by 
programming  subtype  checking — that  is  providing  checks  on 
the  bounds  of  variables  that  would  be  classified  as  subtypes 
and  generating  error  messages  when  they  were  assigned 
improper  values  or  re-assigning  them  automatically  to  values 
within  their  bounds.  For  a  prototype  implementation  of  this 
nature  it  was  felt  that  the  user  could  be  responsible  for 
the  correct  assignment  of  values  to  variables. 

The  T$  and  L$  fields  are  strings  which  determine  the 
symbol's  appearance.  The  contents  of  the  T$  field  is  the 
character  string  required  to  draw  the  symbol.  It  is  copied 
from  the  table  of  symbols  (SYM$),  based  on  the  classifi- 
cation (CLASS$)  of  the  track.   The  speed  leader  is  looked  up 
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in  the  LDR$  table,  based  on  the  track's  course,  and  stored 
in  the  L$  field  for  the  track. 

The  only  remaining  character  string  field  of  the  TRACK 
record  is  HK$ .  This  is  a  string  indicating  whether  the 
track  is  hooked  or  not  (a  hooked  track  is  one  that  has  its 
parameters  displayed  on  the  right  side  of  the  display,  at 
the  user's  request).  Regardless  of  whether  monochrome  or 
color  is  used,  a  means  is  required  to  identify  which  track 
is  currently  hooked  (if  any).  We  elected  to  indicate  this 
by  enlarging  the  symbol.  The  HK$  string,  indicating  scale, 
is  always  added  to  the  T$  string  when  the  symbol  is  drawn. 

The  only  other  data  structures  of  note  are  the  three 
arrays  for  land  masses  which  are  dimensioned  in  the  Land 
module.  They  are  two  dimensional  arrays  in  which  the  (x,y) 
coordinate  pairs  for  points  defining  the  borders  of  land 
masses  (or  other  special  areas)  are  stored.  The  Land  module 
then  displays  these  areas  by  connecting  the  points  with  a 
line  the  color  of  the  land  area  and  painting  the  area  of  the 
screen  bordered  by  that  line  the  same  color. 

There  is  no  true  dynamic  memory  allocation  in  ZBASIC. 
To  circumnaviagate  this  limitation,  the  PTS  array  stores  the 
numbers  of  points  defining  each  land  mass  (three  are 
provided  for  in  this  prototype);  then  the  array  elements  of 
PTS  are  used  to  dimension  the  land  arrays  when  the  Land 
module  is  called.  Multiple  calls  to  the  module  with 
different   values   in   the   PTS   array  generate  errors.   The 
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initialization  of  the  lower  array  subscript  to  one  will 
cause  errors  if  the  elements  of  the  PTS  array  are  lower  than 
one.  For  that  reason  the  PTS  array  elements  are  initialized 
to  ones.  This  problem  also  required  that  each  land  mass 
have  an  array  with  a  separate  name.  That  led,  in  turn,  to 
the  repetition  of  similar  code  in  the  Land  module,  once  for 
each  land  mass. 

C.   DESIGN  DECISIONS 

Some  of  the  decisions  made  have  already  been  discussed. 
Others  are  described  in  an  effort  to  present  some  project 
history  and  design  philosophy  that  may  enlighten  others,  or 
remove  some  of  the  mystique  from  "software  design".  The 
documentation  of  these  decisions  and  their  reasons  should 
also  enhance  maintainability,  and  extend  the  life  cycle  of 
the  project  by  creating  an  environment  of  modif iability . 

The  decision  to  use  the  special  function  keys  for  user 
input  was  born  of  human  factors  engineering.  The  concept  is 
to  make  it  simple  for  the  user  to  make  use  of  the  system. 
In  order  to  make  it  as  simple  as  possible,  a  special 
function  key  menu  is  displayed  at  the  bottom  of  the  display 
(close  to  the  special  function  keys)  which  reminds  the  user 
what  each  of  them  does.  These  keys  are  defined  in  the  Init 
module,  and  restored  in  the  Keys  module  upon  exit  from  the 
system.  We  chose  to  make  extensive  use  of  data  statements 
for  initializing  the  display.   Because  we  also  designed  this 
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prototype  with  mergable  files  (the  data  is  in  one  file)  only 
the  data  file  needs  to  be  different  for  an  entirely 
different  initial  display. 

The  Axes  module  incorporates  three  simple  yet 
significant  design  choices.  The  first  of  these  is  the 
scaling  of  the  divisions  along  the  axes.  This  scaling  was 
discussed  in  Section  II. B. 2. 

The  second  decision  was  the  way  to  draw  the  axes.  As 
shown  in  Figures  3.2-3.3,  presenting  four  distinct  areas 
(background,  land,  symbols,  reference  grid)  on  a  display 
with  only  two  colors  (monochrome  system)  can  be  difficult. 
Even  on  a  color  monitor  problems  arise  when  two  or  more  of 
these  graphic  entities  of  the  same  color  are  drawn  in  the 
same  area  on  the  display.  This  prototype  is  written  for 
full  color  implementation.  The  sample  runs  illustrated  were 
run  with  the  colors  black  and  white,  because  the  H/Z-100 
monitors  currently  in  use  at  NPS  are  monochrome  monitors. 

Figure  3.2  demonstrates  the  obvious  problem.  Where  the 
land  and  the  reference  grid  overlap,  the  reference  grid  does 
not  appear.  In  this  figure  the  land  was  drawn  first. 
Simply  reversing  the  order  of  drawing,  as  expected,  does  not 
solve  the  problem.  It  may  introduce  a  different  problem,  as 
shown  in  Figure  3.3. 

There  are  two  simple  solutions  to  the  problem.   They  are 
shown  in  Figures  3.4-3.5.   Figure  3.4  presents  the  most 
pleasing  appearance.   It  was  created  by  calculating  where 
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Figure  3.2   Reference  Grid  Eclipsed  by  Land 


f   #   f   t   »   t   I 1 1 1 h-H « 1 h 


Figure  3.3   Land  Mass  only  Partially  Painted 
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the  conflicts  would  arise  and  mapping  the  reference  grid  in 
sections,  each  section  the  color  opposite  that  of  the 
background.  This  may  present  the  most  elegant  display,  but 
requires  modification  of  the  actual  Axes  module  every  time 
different  land  is  drawn. 

The  second  method  of  solving  the  conflict  is  illus- 
trated in  Figure  3.5.  After  the  land  is  drawn,  a  wide  line 
the  color  of  the  background  (i.e.,  opposite  that  of  the 
land)  is  drawn  where  the  grid  will  appear,  then  the  grid  is 
drawn  on  top  of  it  in  a  slightly  narrower  line.  The  picture 
is  not  quite  as  elegant,  and  some  of  the  land  features  are 
obscured.  This  solution  does  offer  the  advantage  of  writing 
one  Axes  module  which  will  work  whatever  the  land  for  any 
particular  display  is.  We  employed  this  solution  in  the 
prototype  for  just  that  reason. 

The  Update  module  may  be  considered  the  heart  of  the 
system.  It  presented  several  interesting  design  alterna- 
tives, many  because  of  the  language  limitations  of  ZBASIC. 
The  reader  may  want  to  refer  to  Appendix  G,  which  contains 
the  listing  of  the  code  of  this  module,  during  the  reading 
of  the  following  discussion. 

The  first  choice,  which  is   not  evident  in  examining  the 
code,  was  whether  to  place  the  update  loop  within  this 
module  or  in   the   calling   routine.     The  simulator  should 
periodically  perform   an   automatic   update   of  all  tracks, 
independent  of  user  input.   This  requirement  seemed  to  infer 
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Figure  3.4   Solution  One 


Figure  3.5   Solution  Two 
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that  the  loop  should  be  internal.  Initially  we  provided  the 
loop  in  this  Update  module.  That  worked  fine,  until  user 
interaction  was  added. 

At  any  time  the  user  may  elect  to  delete,  insert,  hook 
or  modify  a  track.  Ideally  he/she  would  not  have  to  wait 
for  the  next  update  of  all  tracks  to  see  the  effect  of  the 
service  request,  but  should  see  it  implemented  immediately. 
For  this  reason  the  loop  was  externalized,  allowing  this 
module  to  be  called  for  the  single  track  being  deleted, 
inserted,  hooked  or  modified. 

We  have  stated  that  many  decisions  were  made  in  the 
interest  of  clarity  rather  than  efficiency.  One  of  the 
exceptions  to  this  rule  is  here,  in  the  early  lines  of  the 
Update  module.  Several  times  within  this  module  reference 
is  made  to  elements  of  the  TRACK  record  structure  (Figure 
3.1).  Calculations  of  the  actual  address  of  an  element  in 
an  array  are  more  time-consuming  than  references  to  simple 
variables.  Almost  all  of  the  array  elements  that  are 
referenced  are  copied  into  local  simple  variables  to  save 
time. 

Because  the  ACTIVE  field  is  referred  to  at  most  twice 
within  Update,  it  was  not  copied  but  is  referred  to 
directly.  The  ACTIVE  field  serves  two  purposes  with  three 
allowable  values.  If  the  value  of  this  field  is  zero,  the 
track  is  inactive  (the  user  no  longer  desires  it  to  be 
displayed),  and  it  is  only  erased.   A  value  of  one  indicates 
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an  active  track,  and  it  is  erased,  updated,  and  re-drawn.  A 
value  of  two  indicates  a  special  type  of  "inactive"  —  a 
symbol  which  does  not  move  (i.e.,  reference  point,  or  target 
with  speed  equal  to  zero).  It  is  not  erased  or  updated, 
merely  re-drawn  (in  case  it  has  been  partially  over-written 
by  another  track). 

The  next  decision  is  one  involving  a  sampling  technique. 
One  common  method  for  erasing  a  figure  in  computer  graphics 
is  to  re-draw  it  in  the  same  color  as  its 
background.   That  is  the  method  we  employ  here. 

This  erasure/re-drawing  could  be  performed  automa- 
tically, in  ZBASIC,  through  the  use  of  the  PUT  and  GET 
statements.  The  code  would  have  been  easier  to  write, 
perhaps  even  quicker  to  execute.  The  problem  with  this  easy 
solution  is  illustrated  in  Figures  3.6-3.7. 

The  use  of  the  PUT  and  GET  statements  is  a  three-step 
process.  The  figure  that  is  going  to  be  moved  is  first 
drawn  somewhere  on  the  screen.  This  has  been  done  in  Figure 
3.6,  providing  the  right-most  symbol.  This  step  precedes 
the  actual  use  of  either  the  PUT  or  the  GET  statement.  Then 
the  GET  statement  is  utilized,  in  the  form  GET  (xl,  yl)  - 
(x2,  y2),  <figure  name)  (A  necessary  preliminary  step, 
before  even  drawing  the  figure,  is  the  use  of  a  DIMension 
statement  to  allocate  memory  for  the  drawing) .  The 
subscripted  x  and  y  values  are  coordinates,  the  first  pair 
for  the  upper  left-hand  corner  of  a  box  on  the  screen  which 
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Figure  3.6  Drawing  a  Symbol  for  use  with  PUT  and  GET 


Figure  3.7  Moving  a  Symbol  using  PUT 
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encloses  the  figure,  the  second  pair  for  the  lower  right- 
hand  corner.  The  amount  of  space  to  set  aside  in  memory 
through  the  DIM  statement  is  dependent  upon  the  size  of  the 
pixel  box  enclosing  the  figure.  Figure  name  is  a  variable 
name  that  is  assigned  to  the  portion  of  memory  where  this 
pixel  box  is  stored.  The  third  and  final  step,  the  use  of 
the  PUT  statement,  is  of  the  form  PUT  (x,  y),  <figure  name). 
The  coordinates  x  and  y  are  of  the  upper  left-hand  corner  of 
an  area  on  the  screen  where  the  upper  left-hand  corner  of 
the  original  figure's  containing  box  is  to  be  placed.  The 
result  will  be  the  placement  of  the  original  figure  where 
the  PUT  statement  has  directed.  Placing  of  a  symbol  with 
the  PUT  statement  is  demonstrated  by  the  white  symbol  in  the 
black  box  in  Figure  3.6. 

There  are  "action  verbs",  optional  commands  which  follow 
the  <figure  name)  in  the  PUT  statement,  which  determine  the 
relationship  in  the  new  location  between  the  figure's  box 
and  the  background  existing  at  the  specified  screen 
location.  Proper  use  of  these  action  verbs  relieves  the 
programmer  of  the  need  to  be  concerned  with  what  the 
background  looks  like  by  automatically  ensuring  that  the 
desired  effect  is  produced  when  the  figure  is  drawn,  and  the 
background  is  restored  when  the  figure  is  erased.  The 
problem  with  all  of  this  is  the  requirement  that  an  entire 
box  of  pixels,  enclosing  the  symbol,  must  be  moved.   The 
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results  of  this  are  illustrated  in  Figures  3.6  and  3.7. 
[Ref  3:  pp.  6.5-6.24] 

A  solution  which  provides  much  cleaner  displays,  and 
obscures  less  background  wherever  a  symbol  is  placed,  is 
shown  in  Figures  3.8-3.9.  The  symbols  are  drawn  using  the 
Graphics  Macro  Language  (GML)  of  ZBASIC  [Ref.  3:  p.  5.5]  in 
Figure  3.8.  The  results  of  moving  them  with  the  Update 
module  are  shown  in  Figure  3.9. 

We  n^ed,  therefore,  some  method  of  determining  the 
background  color  (the  symbol  may  even  rest  on  a  background 
containing  two  colors  in  a  monochrome  display,  or  more  than 
two  in  a  color  display).  We  elected  a  point  sample,  for 
speed  and  simplicity.  There  are  problems  attendant  with 
this  method  when  the  symbol  rests  on  a  multi-colored 
background.  Any  sampling  technique,  other  than  examining 
every  pixel  the  symbol  occupies,  suffers  from  the  same 
problem.  Rather  than  employ  this  time-consuming  process 
(sampling  every  point)  to  solve  what  we  expect  to  be  an 
infrequent  problem,  we  elected  to  use  a  single  point  sample. 
We  chose  to  look  at  a  point  two  pixels  to  the  right  and  one 
pixel  below  the  symbol  center. 

When  this  sampling  is  applied  to  the  new  symbol  position 
we  face  another  decision.  If  the  new  background  is  the  same 
color  as  the  symbol,  what  color  should  the  new  symbol  be 
drawn  in?  For  a  monochrome  display  the  answer  is  already 
determined.     We   elected   to   provide   the    same   choice 


40 


Figure  3.8  Symbols  Drawn  using  GML 


Figure  3.9  Symbols  Moved  using  Update 
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in  the  color  display.  For  the  two  darkest  backgrounds, 
black  and  blue,  the  symbol  is  drawn  in  white.  All  others, 
if  they  match  the  actual  symbol  color,  result  in  a  black 
symbol . 

The  final  decision  involved  track  history.  We  chose  not 
to  store  the  information  anywhere,  partly  due  to  the  lack  of 
dynamic  memory  allocation.  We  did  experiment  with  a  track 
history  display,  however.  It  was  simple  to  implement, 
interesting  to  see,  and  is  left  as  an  exercise  for  the 
reader . 

The  decisions  in  the  Move  module  have  been  addressed 
earlier,  after  a  fashion.  We  chose  to  use  only  eight  speed 
leader  directions.  For  determination  of  the  incremental 
movement  of  the  symbol  across  the  display  we  divided  a 
circle  into  20  sections  (see  Figure  3.10). 

The  actual  listing  of  the  Move  module  code,  Appendix  H, 
looks  more  complex  than  it  is.  The  first  several  lines  of 
code  make  the  division  of  the  circle  (courses  ranging  from 
000  degrees  to  360  degrees),  directing  execution  of  the 
appropriate  statements  to  assign  the  increments  for  the 
horizontal  and  vertical  movement,  as  well  as  the  speed 
leader  direction.  The  GOTO  statements  simply  complete  the 
construction  of  a  giant  case  statement,  transferring  program 
control  to  the  speed  section. 

Here  we  encounter  another  decision:  how  many  different 
states   of  speed  to  recognize.   We  chose  three,  representing 
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slow  targets  (such  as  surface  vessels),  medium  speed  targets 
(aircraft)  and  high-speed  targets  (jet  aircraft  and 
missiles).  Based  on  the  speed  category,  the  speed  leader 
and  the  movement  increments  are  scaled.  The  special  case  of 
a  track  with  zero  speed  is  also  treated,  by  assigning  no 
speed  leader  and  no  incremental  movement. 


22.5   each 


045°  <  CUS  <=  067.5° 


17.5   each 


10' 


Figure  3.10   Target  Course  Increments 

In  the  Tracking  module  we  chose  to  provide  fj  r  the 
possibility  of  existing  tracks  in  the  initial  display.  This 
feature  allows  for  the  establishment  of  various  training 
modules,  each  with  different  initial  track  selections.  If 
there  are  none,  the  code  that  treats  them  is  skipped. 

The  next  section  of  this  module  affects  the  delay 
between  updates.  It  also  provides  the  opportunity  to  the 
user  to  make  a  service  request.   While  all  tracks  are   being 
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updated,  the  user  input  is  ignored.  Then,  for  the  length  of 
time  between  delays,  or  until  the  user  makes  a  service 
request,  the  keyboard  is  repeatedly  checked  for  pressed 
keys.  In  the  Macro-86  implementation,  this  could  be  handled 
through  an  interrupt  service  request.  If  the  user  makes  a 
request,  it  is  checked  for  validity.  We  decided  to  ignore 
invalid  input  rather  than  generate  error  messages.  This  was 
felt  to  be  more  "user  friendly"  and  robust.  Valid  input  is 
the  use  of  any  of  the  special  function  keys  that  have 
defined  functions.  Those  which  are  defined  are  displayed  at 
the  bottom  of  the  screen  in  the  special  function  key  menu, 
as  seen  in  Figures  3.8,  3.9,  3.11  and  3.12. 

The  decisions  made  in  the  Keys  module  were  driven  more 
by  requirement  than  choice,  in  many  cases.  The  "Halt" 
request  clears  the  screen  of  the  display  and  restores  the 
special  function  keys,  as  a  matter  of  good  programming 
practice.  The  "Suspend/Continue"  request  waits  for  another 
input  from  the  keyboard.  We  chose  to  accept  any  key  to 
continue,  again  in  the  interests  of  robustness  and  "user 
friendliness" . 

There  are  some  interesting  requirements  generated  by  a 
request  to  "Hook"  a  track.  We  have  elected  to  have  only  one 
track  hooked  at  a  time.  The  first  thing  this  module  does, 
then,  is  to  check  to  see  if  there  is  a  track  already  hooked. 
If  there  is,  it  must  unhook  it.  This  involves  more  than 
merely  changing  the  HK$  field  in  its  record. 
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Hooked  tracks  are  indicated,  in  i-his  prototype,  by 
enlarged  symbols.  The  enlarged  symbol  of  the  previously 
hooked  track  must  be  erased,  or  the  next  erasure  will  only 
erase  a  small  part  of  it.  After  managing  any  previously 
hooked  track,  the  user  is  asked  to  specify  the  number  of  the 
track  to  hook.  It  is  then  hooked,  its  symbol  enlarged,  and 
the  parameters  of  the  track  displayed  to  the  right  of  the 
screen.  An  example  of  a  hooked  track  display  is  pictured  in 
Figure  3.11.  In  later  implementations,  it  would  be 
desirable  to  indicate  a  track  to  hook  by  either  its  track 
number  or  by  placing  the  cursor  near  it.  This  prototype 
does  not  provide  for  cursor-dependent  user  input. 

The  same  problem,  cursor-independent  user  input, 
surfaces  in  the  "Enter"  request.  The  user  is  asked  to  enter 
track  parameters,  including  "Grid  X"  and  "Grid  Y" .  Details 
of  these  parameters  are  included  in  the  User's  Manual, 
Appendix  N.  Figure  3.12  shows  a  request  for  the  user  to 
enter  the  class  of  a  track  at  the  top  of  the  screen,  in 
response  to  a  depression  of  the  "Enter"  <F3>  key  by  the 
user.  The  problem  re-appears  in  the  "Modify"  function, 
where  the  "Grid  X"  and  "Grid  Y"  of  the  track  are  verified  or 
modified  by  the  user. 

The  Match  module  matches  the  symbol  type  to  the  CLASS$ 
field  of  the  TRACK  record.  Arbitrary  choices  were  made 
here,  and  have  no  bearing  on  actual  NTDS  symbology.  The 
symbols  chosen   and   the   corresponding  classifications  were 
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Figure  3.11  A  Hooked  Track 


Figure  3.12  User  Input  Requested 
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made  simply  to   demonstrate   the   proper   functioning  of  the 
prototype. 
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IV.   PERFORMANCE  TESTS 

A.   TIMING 

We  present  here  the  results  of  selected  timing  tests 
that  were  performed  for  purposes  of  comparison.  The  first 
tests  performed  were  timing  two  primitive  functions  by  the 
prototype  modules  in  each  of  the  two  languages  proposed  and 
used.  The  results  are  presented  in  Table  4.1  and  discussed 
below. 


Window 

Generation 

.6854 

.1300 

TABLE  4.1   TIMING  COMPARISONS,  ZBASIC  AND  MACRO-86 

TEST  #1         TEST  #2 

Symbol 
Generation 

ZBASIC         .6854  .0846 

Macro-86      .1300  .0015 

All  times  in  Table  4.1  are  given  in  seconds.  Test  #1 
was  the  generation  of  the  window  and  the  reference  grid. 
For  the  ZBASIC  timing  the  Window  and  Axes  modules  were  used 
to  generate  100  displays.  The  times  were  noted  and  the 
elapsed  time  computed  and  divided  by  100  to  obtain  the  data 
in  Table  4.1.  To  time  the  Macro-86  routine,  which  does 
generate  a  reference  grid  but  does  not  ensure  freedom  from 
color  conflict  and  does  not  provide  scale  divisions,  one 
display  was  drawn.     Timing   interrupts   were  generated  to 
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allow  the  system  clock  to  time  the  performance.  Although 
the  test  conditions  were  not  identical,  the  test  results 
are  indicative  of  the  order  of  magnitude  of  the  different 
performance  of  the  two  languages. 

Test  #2  timed  the  generation  of  one  symbol.  For  the 
Macro-86  test  the  screen  was  filled  with  2000  symbols,  the 
time  to  do  so  recorded  and  divided  by  2000  to  obtain  the 
result  recorded  above.  For  ZBASIC  1000  symbols  were 
generated  using  the  Update  module.  Because  Update  erases 
each  symbol  and  re-draws  it,  this  was  the  time  required,  in 
effect,  to  draw  2000  symbols.  The  relative  efficiencies  of 
the  two  languages  are  again  exposed,  rather  than  the 
precise  difference  in  time  required  to  perform  the  same 
task. 

Further  timing  tests  were  conducted  using  the  entire 
display  simulator  prototype.  The  results  are  tabulated  in 
Table  4.2  and  disussed  in  the  following  paragraph. 

The  first  three  timing  runs  involve  numbers  of  symbols 
that  are  multiples  of  each  other.  The  times  do  not  follow 
that  exact  correspondence.  This  is  due  to  the  overhead 
involved  in  a  call  to  a  subroutine  and  a  return,  performed 
in  an  iterative  loop.  Even  at  99  symbols,  where  the 
overhead  per  symbol  becomes  negligible,  the  update  time  per 
symbol  may  be  seen  to  exceed  .15  seconds,  almost  twice  the 
time  per  symbol  when  just  the  Update  module  was  tested. 
The   suggested   limitation  of  the  system  this  data  provides 
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is  not  as  serious  as  it  first  seems.  When  only  twenty 
symbols  were  displayed,  it  required  the  operator  more  than 
4.02  seconds  to  digest  the  graphic  information  displayed. 
Of  course,  in  high  density  tactical  pictures,  only  the 
targets  of  immediate  priority  are  concentrated  on. 

TABLE  4.2   PROTOTYPE  SYMBOL  GENERATION  TIMING 

#  of  Symbols  Time  required  to  update  all  tracks 
10  2.07  seconds 

20  4.02  seconds 

40  7.89  seconds 

99  15.27  seconds 

These  initial  timing  results  confirm  our  earlier 
suggestion  that  the  prototype  should  be  (and  has  been) 
developed  in  ZBASIC  in  order  to  be  available  for  use  and 
experimentation  sooner,  but  the  final  system  implemen- 
tation should  be  developed  in  Macro-86  assembly  language. 
Toward  that  end  the  Macro-86  listings  in  Appendices  O-U  are 
provided,  and  the  User's  Manual  for  them  in  Appendix  V. 

B.   EFFICIENCY 

There  are  other  efficiency  issues   to  be  addressed.   As 

has  been  noted  more  than  once,  the  prototype  we  have 
implemented  is  not  the  most  efficient  possible.   It  may   be 

that  when  the  code  has  been   tightened  up  as  much  as  can  be 

the   ZBASIC   implementation  may  suffice.  It  is  our  opinion 

that  it  is,  and  may  continue  to  be,  quite  useful,  but   that 
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a  final  implementation  in  Macro-86   would  be  well  worth  the 
effort. 

Chapter  III  addressed  some  of  the  places  in  which  the 
ZBASIC  code  sacrificed  efficiency  for  clarity.  There  are 
other  indications  of  possible  coding  improvements  suggested 
in  the  User's  Manual  for  the  prototype,  Appendix  N.  More 
suggestions  for  follow-on  efforts  are  addressed  in  the  next 
chapter . 
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V.   CONCLUSION 

A.   USES  OF  THIS  PROTOTYPE 

This  NTDS  display  simulator  prototype  has  been 
developed  as  proof  of  the  feasibility  of  such  a  simulator 
on  the  H/Z-100  microcomputer.  It  demonstrates  the  graphic 
ability  of  the  H/Z-100  to  support  such  a  simulator,  gives 
any  users  actual  displays  to  experiment  with  and  learn 
from,  and  shows  that  such  a  simulator  might  present  real- 
time graphic  updates.  It  may  also  be  used  to  demonstrate 
the  graphics  capability  of  the  H/Z-100. 

The  code  listings  provided,  coupled  with  the  design 
discussions  in  this  text,  document  some  of  the  thought 
processes  and  decision  criteria  involved  in  developing  such 
a  system.  It  may  be  used  without  modification  or  improve- 
ment as  a  simplistic  display  simulator  for  some  of  the 
purposes  put  forth  in  Chapter  I.  It  may  become  the  kernel 
of  a  more  fully  developed  NTDS  system,  using  Ada  as  the 
higher  level  language  and  Macro-86  when  required. 

The  Macro-86  modules  provided  may  be  incorporated  as 
they  are  in  other  systems  to  perform  very  primitive  graphic 
functions.  They  model  the  type  of  development  that  may  be 
considered  for  other  assembly  language  functions  users  may 
want  to  incorporate  in  this  or  other  systems.  They  are 
also  models  of  at  least  one  form  of  internal  documentation. 
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B.  FOLLOW-ON  WORK 

The  display  simulator  prototype  in  ZBASIC  performs  some 
of  the  functions  such  a  system  is  required  to  perform. 
Functions  such  as  track  history  (earlier  alluded  to), 
automatic  track  sequencing,  trouble  tracks  (tracks  which 
have  not  been  updated  recently  enough  by  the  user),  etc., 
could  be  added.  Interfaces  between  the  assembly  language 
modules  included  and  high-level  languages  (such  as  Ada) 
could  be  developed. 

C.  LESSONS  LEARNED 

Many  valuable  lessons  were  learned  during  the  develop- 
ment of  this  prototype.  It  is  not  easy  to  assign  priority 
to  them.  The  order  in  which  they  are  presented  is  not 
meant  to  imply  such  a  prioritization.  Each  lesson  here  was 
valuable,  and  should  be  given  careful  consideration  in  any 
future  development  of  this  project. 

Internal  documentation  is  very  important.  Even  as  a 
simple,  one-programmer  project,  the  internal  documentation 
of  the  code  made  corrective  maintenance  much  easier,  and 
should  enhance  the  maintainability  of  the  code  for  other 
programmers  working  with  it  in  the  future. 

During  prototype  development  such  as  this,  clear  logic 
is  more  important  than  elegant  code.  Keeping  the  logic 
clear  caused  a  proliferation  of  variable  names,  and 
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the  repetition  of  some  sections  of  code,  but  it  greatly 
enhanced  testing  and  debugging. 

ZBASIC  is  a  more  versatile  language  than  it  appears  to 
be.  This  may  verge  on  heresy  in  computer  science  circles, 
and  it  came  as  a  surprise  to  us.  The  ease  with  which  some 
other  high-level  language  constructs  could  be  constructed 
in  ZBASIC  was  an  eye-opener. 

At  the  same  time,  this  project  exposed  some  of  the 
problems  with  ZBASIC  for  systems  work.  The  lack  of  data 
structure  definition  was  a  difficult  problem  to  overcome. 
The  inability  to  specify  sub-types  was  also  an  unpleasant 
reality.  The  real  surprise  was  revealed  in  Table  4.1. 
ZBASIC  had  not  seemed  visibly  much  slower  than  Macro-86, 
but  the  timing  tests  revealed  the  magnitude  of  the 
difference. 

D.   CONCLUSIONS 

The  display  simulator  prototype  has  been  developed. 
The  feasibility  question  has  been  answered.  The  H/Z-100  is 
definitely  capable  of  providing  the  user  with  an  NTDS-type 
display,  and  with  some  of  the  NTDS  user  functions. 

The  display  updates  are  noticeable,  regardless  of  the 
number  of  symbols  in  the  system.  This  feature  will  remain 
in  any  implementation  language,  because  the  re-location  of 
the  symbols  is  in  discrete  steps. 
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The  speed  of  the  updates  is  a  function  of  the  language 
employed.  The  data  in  Table  4.1  provides  evidence  of  the 
savings  in  time  achievable  through  the  use  of  Macro-86 
routines.  The  window  area  alone  may  be  generated  in  less 
than  one-fifth  the  time  in  assembly  language.  Drawing  more 
complex  shapes  on  the  screen  take  even  longer  in  ZBASIC. 
This  is  evidenced  by  the  56-1  time  differential  in  drawing 
a  simple  symbol. 

The  data  in  Table  4.2  is  even  more  revealing  of  the 
inefficiencies  of  ZBASIC  for  real-time  applications.  It  is 
readily  apparent  that  the  symbol  generation  within  the 
prototype,  rather  than  in  a  separate  test  module,  takes 
almost  twice  as  long.  The  additional  time  delay  is  due  to 
the  call-return  sequence,  utilizing  the  Update  module  for 
each  symbol  re-location. 

This  does  not  mean  that  the  prototype  itself  is 
useless.  Fire  control  solutions  require  accurate  solutions 
at  precise  instants  in  time.  Tactical  displays  may  lag  the 
real-time  situation  by  as  much  as  a  few  seconds  and  still 
be  useful  to  the  human  operators.  A  display  simulator, 
which  utilizes  keyboard  input  rather  than  radar  and  other 
equipment  inputs,  is  useful  at  even  slower  speeds. 

We  conclude  that  this  prototype  has  value,  as  discussed 
above.  Future  implementation  of  a  tactical  display 
simulator  on  the  H/Z-100,  in  assembly  language,  and/or 
another  high-level  language,  is  desirable   and   encouraged. 
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APPENDIX  A:  LISTING  OF  NEWEST. BAS 


SAMPLE  NTDS  DISPLAY  SIMULATOR 


FRAME  #7 


PROTOTYPE  DISPLAY 


10  ■ 

20  ' 

30  * 

40  ' 

50  * 

60  ' 

70  CLS        'CLEAR  THE  DISPLAY 

80  ' 

90  ' 

100  ' 

110  ' 

120  ' 

130  OPTION  BASE 

140  ' 

150  DIM  CLASS$(10),  CUS(IO),  SPD(IO),  TCOLOR(IO) 

160  DIM  TX(10),  TY(10),  XINC(IO),  YINC(IO),  T$(10),  L$(10) 

170  DIM  SYM$(10),  LDR$(8),  PTS(3),  LC0L(3),  HK$(10),  ACTIVE(IO) 

180  * 

190  '         SYMBOL  TABLE 

200  ' 

210  SYM$(1) 

220  SYM$(2) 

230  SYM$(3) 

240  SYM$(4) 

250  SYM$(5) 


******  INITIALIZATION  AND  TABLES  *  *  * 


'ARRAY  SUBSCRIPT  LOWER  BOUND  =  1 


"BM+0,-3  R3  D3  BM-6,0  D3  R3  BM+0,+3" 

"BM+0,-3  L3  D3  BM+0,+3" 

"BM+0,-3  R3  D6  L6  U6  R3  BM+0,+3" 

"BM+0,-3  R2  F2  D3  G2  L4  H2  U3  E2  R2  BM+0,+3" 

R3  D3  BM-6,0  U3  R3  BM+0,+3" 


"BM+0,-3 

260  SYM$(6)  =  "BM+0,-3  F3  G3  H3  E3  BM+0,+3" 
270  SYM$(7)  =  "U3  R3  D6  L6  U6  R3  D6  U3" 
280  SYM$(8)  =  "" 
290  SYM$(9)  =  "" 
300  SYM$(10)  =  "" 
310  ' 
320  ' 
330  ' 
340  ' 

350  LDR$(1) 
360  LDR$(2) 
370  LDR$(3) 
380  LDR$(4) 
390  LDR$(5) 
400  LDR$(6) 
410  LDR$(7) 
420  LDR$(8) 
430  ' 
440  ' 
450  ' 
460  ' 


SPEED  LEADER  TABLE 

"U4" 
"E3" 
"R5" 
"F3" 

"D4" 
"G3" 
"L5" 
"H3" 


START  WITH  NO  TRACKS 
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470 

TRACKS 

=   0 

480 

i 

490 

i 

INITIALIZE   PTS 

ARRAY   ELEMENTS   ' 

500 

i 

510 

FOR   I    = 

=   1   TO   3:    PTS(I)    = 

1:    NEXT    I 

520 

i 

530 

i 

DEFINE   FUNCTION  KEYS 

540 

« 

560 

KEY   1, 

CHR$(27)    + 

"S" 

570 

KEY   2, 

CHR$(27)    + 

llrr.ll 

580 

KEY  3, 

CHR$(27)    + 

"U" 

590 

KEY  4, 

CHR$(27)    + 

llyll 

600 

KEY   5, 

CHR$(27)   + 

"W" 

605 

KEY  6, 

CHR$(27)   + 

llpll 

610 

i 

620 

i 

INITIALIZE  HK$ 

AND  ACTIVE 

630 

i 

640 

FOR   I   = 

=   1   TO   10 

650 

HK$(I) 

=   "SO" 

660  ACTIVE(I)    =   0 

670 

NEXT    I 

680 

i 

690 

i 

DISPLAY 

FUNCTION  KEY   FUNCTIONS 

700 

i 

710 

COLOR  0,7 

720 

LOCATE 

25,    5 

730 

PRINT   "   Fl    " 

740 

LOCATE 

25,    19 

750 

PRINT   "    F2   " 

760 

LOCATE 

25,    29 

770 

PRINT   ' 

,   F3   .. 

780 

LOCATE 

25,    40 

790 

PRINT   ' 

•    F4   » 

800 

LOCATE 

25,    52 

810 

PRINT   ' 

'    F5   " 

820 

LOCATE 

25,    64 

830 

PRINT  ' 

'    F6    " 

840 

COLOR  ' 

7,0 

850 

LOCATE 

25,    9 

860 

PRINT   ' 

'SUSP/CONT" 

870 

LOCATE 

25,    24 

880 

PRINT  ' 

'HOOK" 

890 

LOCATE 

25,    34 

900 

PRINT   ' 

'ENTER" 

910 

LOCATE 

25,    45 

920 

PRINT   ' 

"MODIFY" 

930 

LOCATE 

25,    57 

940 

PRINT   ' 

"DELETE" 

950 

LOCATE 

25,    69 

960 

PRINT 

"HALT" 

1000    ' 

TO    1 
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1010 
1020 
1030 
1040 
1050 
1060 
1070 
1080 
1090 
1100 
1110 
1120 
1130 
1140 
1150 
1160 
1170 
1180 
1190 
1200 
1210 
1220 
1230 
1240 
1250 
1260 
1270 
1280 
1290 
1300 
4999 
5000 
5010 
5020 
5030 
5040 
5050 
5060 
5070 
5080 
5090 
5100 
5110 
5120 
5130 
5140 
5150 
5160 
5200 
5210 
5220 


GET  WINDOW  PARAMETERS 
READ  XUL,  YUL,  XLR,  YLR,  CWIND 

DRAW  THE  WINDOW 
JOSUB  5000 

GET  LAND  PARAMETERS 
LEAD  CONTS  'HOW  MANY  LAND  MASSES? 

DRAW  LAND  MASSES 
lOSUB  8000 

GET  GRID  PARAMETERS 

READ  XYAX,  YTOP,  YBOTT,  YCOL 
READ  YXAX,  XLEFT ,  XRITE ,  XCOL 

DRAW  THE  GRID 

lOSUB  5200 

RUN  UPDATE  TESTS 

GOSUB  11000 


END 

* 

*   INPUTS : 


DRAW   WINDOW   SUBROUTINE 


*  * 


* 


XUL,  YUL  -  UPPER  LEFT-HAND  COORDINATES 
XLR,  YLR  -  LOWER  RIGHT-HAND  COORDINATES 
CWIND     -  COLOR  OF  WINDOW 


*  OUTPUT:   SOLID  WINDOW,  XLR  -  XUL  PIXELS  WIDE, 

*  YLR  -  YUL  PIXELS  DEEP,  COLOR  CWIND 

******  *  *  *  *  *  *  *   *  *  *  *  *  ********  *  * 


LINE  (XUL,  YUL)  -  (XLR,  YLR),  CWIND,  BF 
RETURN 


*******    COORDINATE   AXES   SUBROUTINE    * 


*  *  *  *  *  * 


*   INPUTS:   XYAX,  YTOP,  YBOTT   -  VERTICAL  AXIS  COORDINATES      * 
1 
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5230    ' 

JL. 

5240    ' 

JL 

5250    ' 

JL 

5260    ' 

JL 

OUTPUT: 

5270    ' 

JL 

YXAX,  XLEFT,  XRITE  -  HORIZONTAL  AXIS  COORDINATES 
XCOL,  YCOL         -  GRID  COLORS  * 

* 
PROPERLY  SCALED  SET  OF  COORDINATE  AXES,  * 

OF  XCOL  AND  YCOL  * 

5280  '  *  * 

5  9  Q  n      '      **»     ■*-     ***     **-     -1-     -**     ***     J>     **•     J-     •**    J-     «■*-     J-        jl    jl     jl     jl     jl     jl     ju     j»-     jl     - '-     j-     -1-     -'-     -■-     -'-     jl     JV     J> 

5300    ' 

5310    ' 

5320  HSCALE  =  (XRITE  -  XLEFT) /20  'HORIZONTAL  SCALE  MULTIPLIER 

5330  VSCALE  =  HSCALE  *  .46  'VERTICAL  SCALE  MULTIPLIER, 

5340  'FOR  PROPER  ASPECT  RATIO 

5350  *         DRAW  VERTICAL  AXIS 

5360    ' 

5365   LINE    (XYAX-1,    YTOP)    -    (XYAX+1,    YBOTT),    CWIND,    BF 

5370  LINE    (XYAX,    YTOP)    -    (XYAX,    YBOTT),    YCOL 

5380    ' 

5390  '         DRAW  HORIZONTAL  AXIS 

5400    ' 

5405  LINE  (XLEFT,  YXAX-1)  -  (XRITE,  YXAX+1),  CWIND,  BF 

5410  LINE   (XLEFT,    YXAX)    -    (XRITE,    YXAX),   XCOL 

5420    ' 

5430  '         DRAW  HORIZONTAL  SCALE  DIVISIONS,  LEFT 

5440    ' 

5450   FOR  H   =  XYAX  TO  XLEFT  STEP   -HSCALE 

5460        LINE   (H,    YXAX-2)    -    (H,   YXAX+2),   XCOL 

5470        LINE    (H+l,    YXAX-2)    -    (H+l,    YXAX+2),    XCOL 

5480  NEXT   H 

5490    ' 

5500  '         DRAW  HORIZONTAL  SCALE  DIVISIONS,  RIGHT 

5510    ' 

5520   FOR  H   =  XYAX   TO  XRITE   STEP  HSCALE 

5530        LINE    (H,    YXAX-2)    -    (H,   YXAX+2),   XCOL 

5540    LINE  (H+l,  YXAX-2)  (H+l,  YXAX+2),  XCOL 

5550  NEXT  H 

5560    ' 

5570  *         DRAW  VERTICAL  SCALE  DIVISIONS,  UPPER 

5580    ' 

5590   FOR  V   =  YXAX  TO   YTOP   STEP   -VSCALE 

5600    LINE  (XYAX-4,  V)  -  (XYAX+4 ,  V),  YCOL 

5610  NEXT  V 

5620    ' 

5630  '         DRAW  VERTICAL  SCALE  DIVISIONS,  LOWER 

5640    ' 

5650  FOR  V  =  YXAX  TO  YBOTT  STEP  VSCALE 

5660        LINE    (XYAX-4,    V)    -    (XYAX+4,    V),    YCOL 

5670  NEXT  V 

5680    ' 

5690  RETURN 

5700    ' 

5710    ' 
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5720 
5730 
5740 
5750 
5760 
6000 
6010 
6020 
6030 
6040 
6050 
6060 
6070 
6080 
6100 
6120 
6130 
6140 
6150 
6160 
6170 
6180 
6190 
6200 
6210 
6220 
6230 
6240 
6250 
6255 
6260 
6270 
6280 
6290 
6295 
6300 
6305 
6310 
6320 
6330 
6340 
6350 
6360 
6370 
6374 
6375 
6376 
6380 
6390 
6400 
6410 


•U   JU   JL» 


THIS  AXES  SUBROUTINE  IS  BASED  ON  THE  PROGRAM 
9-2,  PAGE  9-15,  IN  THE  CONTINUING  EDUCATION 
CORRESPONDENCE  COURSE  "COMPUTER  GRAPHICS", 
WRITTEN  FOR  HEATHKIT/ZENITH  BY 

JAMES   C.   ADAMS 
lr  *  *    UPDATE   TRACKS   SUBROUTINE    *  *  *  *  1 


INPUTS:   UPD  -  #  OF  TRACK  TO  UPDATE 


OUTPUT:   TRACK  UPD  IS  UPDATED 


* 


************* 


*  *  * 


*  * 


PERFORM  ALL  LOOK-UPS  ONLY  ONCE 

UPDX  =  TX(UPD) 

UPDY  =  TY(UPD) 

UPDT$  =  HK$(UPD)  +  T$(UPD) 

UPDL$  =  L$(UPD) 

HORZUP  =  XINC(UPD) 

VERTUP  =  YINC(UPD) 

COLUP  =  TCOLOR(UPD) 


UPGND  =  POINT(UPDX+2,  UPDY+1 

ON  UPGND+1  GOSUB  6520,  6530, 

WANT$  =  C0L$  +  UPDT$:  ALSO$ 
i 

PSET  (UPDX,  UPDY),  UPGND 

DRAW  WANT$ 

PSET  (UPDX,  UPDY),  UPGND 

DRAW  ALSO$ 

DRAW  "SO" 
i 

IF  ACTIVE(UPD)  =  0  THEN  6490 

UPDX  =  UPDX  +  HORZUP 

UPDY  =  UPDY  +  VERTUP 
i 

UPGND  =  POINT (UPDX+2,  UPDY+1 ] 
i 

IF  UPGND  <>  COLUP  THEN  6375 

IF  UPGND  <  2  THEN  COLUP  =  7 
i 

ON  COLUP+1  GOSUB  6520,  6530, 

WANT$  =  C0L$  +  UPDT$:  ALS0$ 
t 

PSET  (UPDX,  UPDY),  COLUP 

DRAW  WANT$ 

PSET  (UPDX,  UPDY),  COLUP 


) 

6540,  6550,  6560,  6570,  6580,  6590 
=  C0L$  +  UPDL$ 

'DRAW  OLD  SYMBOL  IN 
'REVERSE  COLOR 


'UPDATE  POSITION 


)  'CHECK  BACKGROUND  COLOR 

OF  NEW  LOCATION 
'MAKE  SYMBOL  OPPOSITE 
ELSE  COLUP  =0     'OF  BACKGROUND 

6540,  6550,  6560,  6570,  6580,  6590 
=  C0L$  +  UPDL$ 

'DRAW  NEW  SYMBOL 
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6420 
6425 
6430 
6440 
6450 
6460 
6480 
6490 
6500 
6510 
6520 
6530 
6540 
6550 
6560 
6570 
6580 
6590 
7000 
7010 
7020 
7030 
7040 
7050 
7060 
7070 
7080 
7090 
7100 
7110 
7130 
7140 
7150 
7160 
7170 
7180 
7190 
7200 
7210 
7220 
7230 
7240 
7250 
7260 
7270 
7280 
7290 
7300 
7310 
7320 
7330 


DRAW  ALSO$ 

DRAW  "SO" 
t 

TX(UPD)  =  UPDX 

TY(UPD)  =  UPDY 
i 

i 

RETURN 


COL$  =  "CO":  RETURN 

COL$  =  "CI":  RETURN 

COL$  =  "C2":  RETURN 

COL$  =  "C3":  RETURN 

COL$  =  "C4":  RETURN 

COL$  =  "C5":  RETURN 

COL$  =  "C6":  RETURN 

COL$  =  "C7":  RETURN 

*******    SYMBOL 


'STORE  NEW  POSITION 


MOVEMENT   CALCULATOR 


INPUTS :   MOVE 


TRACK  TO  CALCULATE  FOR 


OUTPUT : 


*  * 


XINC,  YINC,  SCALE  FACTOR  FOR  SPEED 
LEADER  OF  EACH  ACTIVE  TRACK  ARE 
CALCULATED  AND  STORED 


*  *  * 

* 

* 
* 

* 


*  *  * 


*  *  * 


.•-  j.    -•-  ~»-  -*-  jl 


*  * 


CALCULATE  INCREMENTS  BASED  ON  COURSE 


IF  CUS 
IF  CUS 
IF  CUS 
IF  CUS 
IF  CUS 
IF  CUS 
IF  CUS 
IF  CUS 
IF  CUS 
IF  CUS 
IF  CUS 
IF  CUS 
IF  CUS 
IF  CUS 
IF  CUS 
IF  CUS 
IF  CUS 
IF  CUS 


(MOVE 
(MOVE 
(MOVE 
(MOVE 
(MOVE 
(MOVE 
(MOVE 
(MOVE 
(MOVE 
(MOVE 
(MOVE 
(MOVE 
(MOVE 
(MOVE 
(MOVE 
(MOVE 
(MOVE 
(MOVE 


5 

22.5 

45 

67.5 

85 

95 

112.5 

135 

157.5 

175 

185 

202.5 

225 

247.5 

265 

275 

292.5 

315 


THEN 
THEN 
THEN 
THEN 
THEN 
THEN 
THEN 
THEN 
THEN 
THEN 
THEN 
THEN 
THEN 
THEN 
THEN 
THEN 
THEN 
THEN 


7400 
7410 
7420 
7430 
7440 
7450 
7460 
7470 
7480 
7490 
7500 
7510 
7520 
7530 
7540 
7550 
7560 
7570 
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7340 
7350 
7360 
7370 
7400 
7410 
7420 
7430 
7440 
7450 
7460 
7470 
7480 
7490 
7500 
7510 
7520 
7530 
7540 
7550 
7560 
7570 
7580 
7590 
7595 
7600 
7610 
7620 
7630 
7640 
7641 
7642 
7643 
7644 
7645 
7650 
7660 
7670 
7680 
7690 
7700 
7710 
7720 
7760 
7770 
7780 
8000 
8010 
8020 
8025 
8030 


IF  CUS(MOVE)  <=  337.5  THEN  7580 
IF  CUS(MOVE)  <=    355  THEN  7590 


XINC(MOVE) 
XINC(MOVE) 
XINC(MOVE) 
XINC(MOVE) 
XINC(MOVE) 
XINC(MOVE) 
XINC(MOVE) 
XINC(MOVE) 
XINC(MOVE) 
XINC(MOVE) 
XINC(MOVE) 
XINC(MOVE) 
XINC(MOVE) 
XINC(MOVE) 
XINC(MOVE) 
XINC(MOVE) 
XINC(MOVE) 
XINC(MOVE) 
XINC(MOVE) 
XINC(MOVE) 
XINC(MOVE) 


8:  YINC(MOVE)  =  0: 
7:  YINC(MOVE)  =  -3: 
5:  YINC(MOVE)  =  -5: 
5:  YINC(MOVE)  =  -5: 
3:  YINC(MOVE)  =  -7: 
0:  YINC(MOVE)  =  -8: 
-3:  YINC(MOVE)  =  -7 
-5:  YINC(MOVE)  =  -5 
-5:  YINC(MOVE)  =  -5 
-7:  YINC(MOVE)  =  -3 
-8:  YINC(MOVE)  =  0: 
-7:  YINC(MOVE)  =  3: 
-5:  YINC(MOVE)  =  5: 
-5:  YINC(MOVE)  =  5: 
-3:  YINC(MOVE)  =  7: 
0:  YINC(MOVE)  =  8 
3:  YINC(MOVE)  =  7: 
5:  YINC(MOVE)  =  5 
5:  YINC(MOVE)  =  5: 
7:  YINC(MOVE)  =  3 
8:  YINC(MOVE)  =  0: 


L$(MOVE)  = 
L$(MOVE)  ■ 
L$(MOVE)  = 
L$(MOVE)  i 
L$(MOVE)  = 
L$(MOVE)  = 
L$(MOVE) 
L$(MOVE) 
L$(MOVE) 
L$(MOVE) 
L$(MOVE)  = 
L$(MOVE)  = 
L$(MOVE)  ■ 
L$(MOVE)  = 
L$(MOVE)  = 
L$(MOVE)  = 
L$(MOVE)  = 
L$(MOVE)  = 
L$(MOVE)  = 
L$(MOVE)  = 
L$(MOVE)  = 


LDR$(3): 
=  LDR$(2) 
'  LDR$(2) 

■  LDR$(2) 

■  LDR$(2) 

■  LDR$(1) 
=  LDR$(8 
=  LDR$(8 
=  LDR$(8 
=  LDR$(8 
'  LDR$(7) 

■  LDR$(6) 
'  LDR$(6) 
'  LDR$(6) 
'  LDR$(6) 

LDR$(5) : 
LDR$(4): 
LDR$(4) : 
LDR$(4): 
LDR$(4)  : 
LDR$(3): 


GOTO  7600 

:  GOTO  7600 

:  GOTO  7600 

:  GOTO  7600 

:  GOTO  7600 

:  GOTO  7600 

):  GOTO  7600 

)  :  GOTO  7600 

):  GOTO  7600 

) :  GOTO  7600 

:  GOTO  7600 

:  GOTO  7600 

:  GOTO  7600 

:  GOTO  7600 

:  GOTO  7600 

GOTO  7600 

GOTO  7600 

GOTO  7600 

GOTO  7600 

GOTO  7600 

GOTO  7600 


CALCULATE  AMOUNT  OF  INCREMENT,  SPEED  LEADER 
SCALE,  BASED  ON  SPEED 


IF  SPD(MOVE)  >=  100  THEN  7690 
IF  SPD(MOVE)  <>  0  THEN  7650 
XINC(MOVE)  =  0 
YINC(MOVE)  =  0 
L$(M0VE)  =  "" 
GOTO  7770 
XINC(MOVE)  =  INT(.5  *  XINC(MOVE)) 
YINC(MOVE)  =  INT(.T  *  YINC(MOVE)) 
L$(M0VE)  =  "S2"  +  L$(M0VE) 
GOTO  7770 
IF  SPD(MOVE)  <=  600  THEN  7770 

XINC(MOVE)  =  INT (2  *  XINC(MOVE)) 
YINC(MOVE)  =  INT(2  *  YINC(MOVE)) 
L$(M0VE)  =  "S8"  +  L$(M0VE) 


RETURN 

i 

1  ****** 
•  * 


DRAW   LAND   SUBROUTINE 


*  *  * 


*  * 


*  INPUTS:   PTS  -  ARRAY  OF  #s  OF  BORDER  POINTS 

*  CONTS  -  #  OF  LAND  MASSES 


* 
* 
* 
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8040    '    *      OUTPUT:       PLOTTED  LAND  MASSES,    IN   SPECIFIED   COLORS        * 
8050    '    *  * 

QAAO    '    »L   JU   JL   ^.   J.   ^   J.   J.   J,   J.   J.   JL   .«.      JL.   JL   J-   J-   JC   J.   JU   JL   JL   JL   J!-   J-   J-   -A.   »»* 

q  ^  \j  \j  «       «       '*       "       **       "       '*       «       **       «       n       *\       *\  *\       *\       *\       t\       /\       *\       *\       *s       *\       r%       /*       /%       *\       /*       /» 

8070    ' 

8075    IF   CONTS    =    0   THEN  RETURN  'NO   LAND  MASSES,    NO   DRAW 

8080    ' 

8090   FOR   I    =    1    TO    CONTS 

8100        READ  PTS(I),    LCOL(I) 

8110   NEXT   I 

8120    ' 

8125   DIM  LAND1(PTS(1),    2),    LAND2(PTS(2) ,    2),    LAND3(PTS(3) ,    2) 

8130   FOR   ISLE   =   1   TO  PTS(l) 

8140        READ  LAND1(ISLE,    1),    LAND1(ISLE,    2) 

8150  NEXT   ISLE 

8160    ' 

8170   FOR   ISLE  =   1   TO  PTS(2) 

8180        READ  LAND2( ISLE,    1),   LAND2(ISLE,    2) 

8190  NEXT   ISLE 

8200    ' 

8210   FOR  ISLE  =   1   TO  PTS(3) 

8220        READ  LAND3(ISLE,    1),   LAND3(ISLE,    2) 

8230  NEXT   ISLE 

8240    ' 

8250   PSET    (LAND1(1,1),    LAND1(1,2)),    LCOL(l) 

8260   FOR   ISLE   =   2  TO  PTS(l) 

8270        LINE   -    (LAND1(ISLE,    1),    LAND1(ISLE,    2)),    LCOL(l) 

8280  NEXT   ISLE 

8290    ' 

8300  READ  CENTX,    CENTY 

8310    ' 

8320   PAINT    (CENTX,    CENTY),    LCOL(l),    LCOL(l) 

8330    ' 

8340   IF   PTS(2)    <    2   THEN  RETURN 

8350    ' 

8360  PSET   (LAND2(1,1),    LAND2(1,2)),    LCOL(2) 

8370   FOR  ISLE   =    2   TO  PTS(2) 

8380        LINE   -    (LAND2(ISLE,    1),    LAND2(ISLE,    2)),    LCOCL(2) 

8390  NEXT   ISLE 

8400    ' 

8410  READ  CENTX,    CENTY 

8420    ' 

8430   PAINT    (CENTX,    CENTY),    LCOL(2),    LCOL(2) 

8440    ' 

8450   IF   PTS(3)    <    2   THEN  RETURN 

8460    ' 

8470   PSET    (LAND3(1,1),    LAND3(1,2)),    LCOL(3) 

8480   FOR   ISLE   =   2  TO  PTS(3) 

8490        LINE    -    (LAND3(ISLE,    1),    LAND3(ISLE,    2)),    LCOCL(3) 

8500  NEXT   ISLE 

8510    ' 

8520  READ  CENTX,    CENTY 
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8530  ' 

8540  PAINT  (CENTX,  CENTY) ,  LCOL(3),  LCOL(3) 

8550  ' 

8560  RETURN 

10000  '  ************   DATA   ************** 

10010  ' 

10020  '   XUL,  YUL,  XLR,  YLR,  CWIND 

10030  ' 

10040  DATA  15,  27,  470,  190,  7 

10050  * 

10060  '  CONTS 

10070  * 

10080  DATA  3 

10090  ' 

10100  '   PTS,  LCOL,  #  OF  TIMES  THERE  ARE  LAND  MASSES 

10110  ' 

10120  DATA  13,  0 

10130  DATA  8,  2 

10140  DATA  10,  1 

10150  ' 

10160  '   BORDER  POINTS  FOR  LAND  MASSES 

10170  ' 

10180  DATA  16,  155,  55,  172,  90,  175,  130,  165,  175,  150,  175,  127 

10190  DATA  210,  110,  180,  85,  260,  67,  245,  45,  160,  28,  16,  28,  16,  155 

10200  ' 

10210  ' 

10220  ' 

10230  DATA  330,  155,  360,  165,  400,  160,  440,  140,  385,  125,  340,  133 

10240  DATA  370,  142,  330,  155 

10250  * 

10260  ' 

10270  ' 

10280  DATA  385,  40,  405,  45,  400,  60,  380,  65,  365,  60,  375,  52 

10290  DATA  350,  52,  370,  45,  390,  55,  385,  40 

10300  ' 

10310  '    CENTERS  OF  LAND  MASSES 

10320  ' 

10330  DATA  100,  90 

10340  ' 

10350  DATA  380,  150 

10360  ' 

10370  DATA  380,  60 

10380  * 

10390  *    XYAX,  YTOP,  YBOTT,  YCOL 

10400  ' 

10410  DATA  157,  27,  190,  0 

10420  ' 

10430  '    YXAX,  XLEFT,  XRITE,  XCOL 

10440  ' 

10450  DATA  145,  15,  470,  0 

10460  ' 
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10470 
10480 
10490 
10500 
10510 
10520 
10530 
10540 
10550 
10560 
10570 
10580 
10590 
10600 
11000 
11010 
11020 
11030 
11040 
11050 
11060 
11070 
11080 
11090 
11100 
11110 
11120 
11125 
11130 
11135 
11140 
11150 
11160 
11165 
11170 
11175 
11180 
11190 
11200 
11210 
11220 
11225 
11230 
11235 
11240 
11250 
11255 
11260 
11270 
11280 
11300 


NUMBER  OF  TEST  TRACKS 
DATA  3 

CLASS$,  CUS,  SPD,  TCOLOR,  TX,  TY   FOR  EACH  TEST  TRACK 

DATA  "HOSTILE   ",  180,  35,  0,  420,  80 

DATA  "SURVEILL  ",  4,  135,  0,  50,  100 

DATA  "UNKNOWN   ",  110,  650,  0,  430,  170 

NUMBER  OF  MOVES  TO  TEST  UPDATING 


DATA  10 

*******    TEST   TRACKING   SUBROUTINE 


*  INPUTS:   TRACKS  -  #  OF  TEST  TRACKS 
* 

*  OUTPUT:   SAMPLE  OF  TRACKS  BEING  UPDATED 


*  * 


******* 


.'.  .'.  j. 


*  *  *  * 


>»-  .t,  .•-  -'.  ~*. 


JL.   JU   JU   JU 

* 
* 
* 
* 
* 
*   *   * 


READ  TRACKS 
i 

IF  TRACKS  =  0  THEN  11200 
FOR  I  =  1  TO  TRACKS 

READ  CLASS$(I),  CUS(I),  SPD(I),  TCOLOR(I),  TX(I),  TY(I) 

UPD  =  I 

GOSUB  20000 

ACTIVE(I)  =  1 
NEXT  I 


FOR  MOVE  =  1  TO  TRACKS 

GOSUB  7000 

NEXT  MOVE 
i 

i 


DO$ 


WHILE  DO$  =  "" 

FOR  UPD  =  1  TO  TRACKS 

GOSUB  6000 
NEXT  UPD 
FOR  I  -  1  TO  2000 

D0$  =  INKEY$ 

IF  D0$  =  ""  THEN  NEXT  I  ELSE  11280 

WEND 
t 

IF  DO$  <>  CHR$(27)  THEN  11200  ELSE  D02$  =  INKEY$ 
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11310 
11320 
11330 
11340 
11350 
11360 
11370 
11380 
11390 
12000 
12010 
12020 
12030 
12040 
12050 
12060 
12062 
12064 
12066 
12068 
12070 
12072 
12074 
12080 
12085 
12090 
12100 
12110 
12120 
12130 
12140 
12150 
12160 
12170 
12180 
12190 
12200 
12210 
12220 
12230 
12240 
12250 
12252 
12254 
12256 
12258 
12259 
12260 
12270 
12275 
12276 


IF  D02$ 
IF  D02$ 
IF  D02$ 
IF  D02$ 
IF  D02$ 
IF  D02$ 

GOTO  11200 


"P"  THEN  GOSUB  12000 
"S"  THEN  GOSUB  12100 
"T"  THEN  GOSUB  12200 
"U"  THEN  GOSUB  12500 
"V"  THEN  GOSUB  12800 
"W"  THEN  GOSUB  13500 


FUNCTION   KEY   SUBROUTINES 


'  7o  7»  7.  7»  1     HALT  PROGRAM 

1  FUNCTION  KEY  F6 

i 

CLS 

KEY  1,  "LIST  " 

KEY  2,  "RUN"  +  CHR$(13)  +  CHR$(10) 

KEY  3,  "LOAD"  +  CHR$(34) 

KEY  4,  "SAVE"  +  CHR$(34) 
i 

KEY  5,  "CONT"  +  CHR$(13)  +  CHR$(10) 

KEY  6,  "PRINT  " 

END 

RETURN 


'  7o  7o  7,  7,  7o   SUSPEND/CONTINUE   PROGRAM 
'  FUNCTION  KEY  Fl 


GO$  =  "" 

WHILE  GO$  =  "" 

GO$  =  INKEY$ 

WEND 
i 

RETURN 

'  7,  7c  7,  7o  7o  HOOK  TRACK 

1  FUNCTION  KEY  F2 

i 

LOCATE  2,  10 
i 

IF  HOOK  =  0  THEN  12270 
ACTIVE (HOOK)  =  0 
UPD  =  HOOK 
GOSUB  6000 
ACTIVE (HOOK)  =  1 
HK$(HOOK)  =  "SO" 

INPUT  "TRACK  TO  HOOK:  ";HOOK 
LOCATE  2,  10 
PRINT  " 
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12280 
12282 
12284 
12286 
12288 
12290 
12300 
12310 
12320 
12330 
12340 
12350 
12360 
12370 
12380 
12390 
12400 
12410 
12420 
12500 
12510 
12520 
12530 
12540 
12550 
12560 
12570 
12571 
12572 
12573 
12574 
12575 
12576 
12580 
12590 
12595 
12596 
12600 
12610 
12615 
12616 
12620 
12630 
12635 
12636 
12640 
12650 
12655 
12656 
12660 
12670 


ACTIVE(HOOK)  =  0 

UPD  =  HOOK 

GOSUB  6000 

ACTIVE(HOOK)  =  1 

HK$(H00K)  =  "S8" 
i 

LOCATE  6,  6  2 

PRINT  "TRACK  NO.  ";H00K 

LOCATE  7,  6  2 

PRINT  "CLASS   ";CLASS$(HOOK) 

LOCATE  8,  6  2 

PRINT  "COURSE   ";CUS(HOOK) 

LOCATE  9,  6  2 

PRINT  "SPEED   ";SPD(HOOK) 
i 

i 

RETURN 


1  7o  7o  7,  7.  7.   ENTER  NEW  TRACK 

1  FUNCTION  KEY  F3 


TRACKS  =  TRACKS  +  1 

MOVE  =  TRACKS 
t 

LOCATE  2,  10 

INPUT  "ENTER  CLASS    "; CLASS $( TRACKS) 

SIZECL  =  LEN(CLASS$ (TRACKS)) 

IF  SIZECL  <  9  THEN  ADD  -   9  -  SIZECL 

IF  ADD  =  0  THEN  12575 

FOR  I  =  1  TO  ADD: CLASS $ (TRACKS)  =  CLASS $ (TRACKS)  +  "  ":NEXT  I 

LOCATE  2,  10 

PRINT  "  " 

2,  10 

ENTER  COURSE   " ;CUS (TRACKS) 

2,  10 


LOCATE 
INPUT  ' 
LOCATE 
PRINT  ' 
LOCATE 
INPUT  * 
LOCATE 
PRINT  ' 
LOCATE 
INPUT  ' 
LOCATE 
PRINT  ' 
LOCATE 
INPUT  ' 
LOCATE 
PRINT  ' 
LOCATE 
INPUT  ' 


2,  10 

ENTER  SPEED    " ;SPD(TRACKS) 

2,  10 

2,  10 

ENTER  GRID  X   ";TX(TRACKS) 

2,  10 

2,  10 

ENTER  GRID  Y   "; TY ( TRACKS ) 

2,  10 

2,  10 

TRACK  COLOR   "  ;TC0L0R( TRACKS) 
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12680 
12690 
12700 
12705 
12710 
12712 
12715 
12716 
12717 
12720 
12730 
12740 
12750 
12800 
12810 
12820 
12830 
12832 
12834 
12836 
12838 
12839 
12840 
12850 
12855 
12856 
12860 
12870 
12872 
12874 
12876 
12878 
12879 
12880 
12890 
12900 
12910 
12915 
12916 
12920 
12930 
12940 
12950 
12955 
12956 
12960 
12970 
12980 
12990 
12995 
12996 


LOCATE  2,  10 

PRINT  " 
i 

GOSUB  20000 

GOSUB  7000 

UPD  =  MOVE 

GOSUB  20000 

HK$(UPD)  =  "SO":  ACTIVE(UPD)  =  1 

GOSUB  6000 
t 

RETURN 


*  7c  7.  7o  7,  7,  MODIFY  TRACK 

1  FUNCTION  KEY  F4 

i 

IF  HOOK  =  0  THEN  12840 

ACTIVE (HOOK)  =  0 

UPD  =  HOOK 

GOSUB  6000 

ACTIVE(HOOK)  =  1 

HK$(H00K)  =  "SO" 

LOCATE  2,  10 

INPUT  "TRACK  TO  MODIFY:  ";H00K 

LOCATE  2,  10 

PRINT  " 
i 

GOSUB  12300 

ACTIVE(HOOK)  =  0 

UPD  =  HOOK 

GOSUB  6000 

ACTIVE(HOOK)  =  1 

HK$(H00K)  =  "SO" 
t 

LOCATE  2,  10 

INPUT  "IS  CLASS  OK  ";A$ 

IF  A$  <>  "Y"  THEN  LOCATE  2,  40:  INPUT 

LOCATE  2,  10 

PRINT  " 
t 


'NEW  CLASS  :";CLASS$(H00K) 


LOCATE  2,  10 

INPUT  "IS  COURSE  OK  ";A$ 

IF  A$  <>  "Y"  THEN  LOCATE  2,  40:  INPUT  "NEW  COURSE: " ;CUS (HOOK) 

LOCATE  2,  10 

PRINT  " 
i 

LOCATE  2,  10 

INPUT  "IS  SPEED  OK  ";A$ 

IF  A$  <>  "Y"  THEN  LOCATE  2,  40:  INPUT  "NEW  SPEED: " ;SPD(HOOK) 

LOCATE  2,  10 

PRINT  "  " 
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13000 
13010 
13020 
13030 
13035 
13036 
13040 
13050 
13060 
13070 
13075 
13076 
13080 
13090 
13100 
13110 
13115 
13116 
13120 
13130 
13140 
13145 
13147 
13150 
13160 
13170 
13500 
13510 
13520 
13530 
13540 
13550 
13560 
13565 
13566 
13570 
13580 
13590 
20000 
20010 
20020 
20030 
20040 
20050 
20060 
20070 
20080 
20090 
20100 
20110 
20120 


LOCATE  2,  10 

INPUT  "IS  COLOR  OK  ";A$ 

IF  A$  <>  "Y"  THEN  LOCATE  2,  40:  INPUT  "NEW  COLOR: " ;TC0L0R(H00K) 

LOCATE  2,  10 

PRINT  "  " 

i 

LOCATE  2,  10 

INPUT  "IS  GRID  X  OK  ";A$ 

IF  A$  <>  "Y"  THEN  LOCATE  2,  40:  INPUT  "NEW  GRID  X:";TX(HOOK) 

LOCATE  2,  10 

PRINT  "  » 

i 

LOCATE  2,  10 

INPUT  "IS  GRID  Y  OK  ";A$ 

IF  A$  <>  "Y"  THEN  LOCATE  2,  40:  INPUT  "NEW  GRID  Y:";TY(HOOK) 

LOCATE  2,  10 

PRINT  "  " 

i 

MOVE  =  HOOK 

GOSUB  7000 

UPD  =  HOOK 

GOSUB  6000 
i 

RETURN 
t 


*  7.  7o  7„  7.  7, 


DELETE  A  TRACK 

FUNCTION  KEY  F5 


LOCATE  2,  10 

INPUT  "TRACK  TO  DELETE:  ";DEL 

ACTIVE(DEL)  =  0 

LOCATE  2,  10 

PRINT  " 
i 

RETURN 


I  J. 

I  J. 

I  J. 

I  J. 

I  J. 

I  J. 


*  *  * 


SYMBOL   ASSIGNMENT 


*  *  * 


INPUTS:   UPD  -  TRACK  TO  HAVE  SYMBOL  ASSIGNED   * 

OUTPUT:   TRACK(UPD)  IS  ASSIGNED  A  SYMBOL      * 
THAT  MATCHES  ITS  CLASSIFICATION      * 

* 


J-   JU  J. 


*******  *  *  * 


-»-  -'.  .<-  .'- 


J.   X   J.   X  J. 


IF  CLASS$(UPD)  =  "HOSTILE   "  THEN  T$(UPD)  =  SYM$(4):  GOTO  20240 
i 

IF  CLASS$(UPD)  =  "HOST  SURF"  THEN  T$(UPD)  =  SYM$(6):  GOTO  20240 
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20130  ' 

20140  IF  CLASS$(UPD)  =  "UNKNOWN 

20150  ' 

20160  IF  CLASS$(UPD)  =  "UNK  AIR 

20170  ' 

20180  IF  CLASS$(UPD)  =  "FIGHTER 

20190  ' 

20200  IF  CLASS$(UPD)  =  "SURVEILL 

20210  ' 

20220  IF  CLASS$(UPD)  =  "REF  PNT 

20230  ' 

20240  RETURN 

20250  ' 


"  THEN  T$(UPD) 
"  THEN  T$(UPD) 
"  THEN  T$(UPD) 
"  THEN  T$(UPD) 
"  THEN  T$(UPD) 


SYM$(3):  GOTO  20240 

SYM$(5):  GOTO  20240 

SYM$(2):  GOTO  20240 

SYM$(1):  GOTO  20240 

SYM$(7):  GOTO  20240 
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APPENDIX  B:   LISTING   OF   HEADER. BAS 


10  '  SAMPLE  NTDS  DISPLAY  SIMULATOR 

20  ' 

30  '  FRAME  #1 

40  ' 

50  '  DISPLAY  WINDOW  WITH  GRID 

60  ' 

70  CLS  'CLEAR  THE  DISPLAY 

80  ' 

90  ' 
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APPENDIX  C:   LISTING  OF   INIT.BAS 


100  '  *  *  *  *  *  *  *  *   INITIALIZATION  AND  TABLES   *  *  *  *  *  *  *  * 

110  ' 

120  ' 

130  OPTION  BASE  1  'ARRAY  SUBSCRIPT  LOWER  BOUND  =  1 

140  ' 

150  DIM  CLASS$(10),  CUS(IO),  SPD(IO),  TCOLOR(IO) 

160  DIM  TX(10),  TY(10),  XINC(IO) ,  YINC(IO),  T$(10),  L$(10) 

170  DIM  SYM$(10),  LDR$(8),  PTS(3),  LC0L(3),  HK$(10),  ACTIVE(IO) 

180  ' 

190  '  SYMBOL  TABLE 

200  ' 

210  SYM$(1)  =  "BM+0,-3  R3  D3  BM-6,0  D3  R3  BM+0,+3" 

220  SYM$(2)  =  "BM+0,-3  L3  D3  BM+0,+3" 

230  SYM$(3)  =  "BM+0,-3  R3  D6  L6  U6  R3  BM+0,+3" 

240  SYM$(4)  =  "BM+0,-3  R2  F2  D3  G2  L4  H2  U3  E2  R2  BM+0,+3" 

250  SYM$(5)  =  "BM+0,-3  R3  D3  BM-6,0  U3  R3  BM+0,+3" 

260  SYM$(6)  =  "BM+0,-3  F3  G3  H3  E3  BM+0,+3 

270  SYM$(7)  =  "U3  R3  D6  L6  U6  R3  D6  U3" 

280  SYM$(8)  =  "" 

290  SYM$(9)  =  "" 

300  SYM$(10)  =  "" 

310  ' 

320  ' 

330  '  SPEED  LEADER  TABLE 

340  ' 

350  LDR$(1)  =  "U4" 

360  LDR$(2)  =  "E3" 

370  LDR$(3)  =  "R5" 

380  LDR$(4)  =  "F3" 

390  LDR$(5)  =  "D4" 

400  LDR$(6)  =  "G3" 

410  LDR$(7)  =  "L5" 

420  LDR$(8)  =  "H3" 

430  ' 

440  ' 

450  *  START  WITH  NO  TRACKS 

460  ' 

470  TRACKS  =  0 

480  ' 

490  *  INITIALIZE  PTS  ARRAY  ELEMENTS  TO  1 

500  ' 

510  FOR  I  =  1  TO  3:  PTS (I)  =  1:  NEXT  I 

520  ' 

530  '  DEFINE  FUNCTION  KEYS 

540  ' 

560  KEY  1,  CHR$(27)  +  "S" 
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570  KEY  2,  CHR$(27)  +  "T" 

580  KEY  3,  CHR$(27)  +  "U" 

590  KEY  4,  CHR$(27)  +  "V" 

600  KEY  5,  CHR$(27)  +  "W" 

605  KEY  6,  CHR$(27)  +  "P" 

610  ' 

620  ' 

INITIALIZE  HK$  AND  ACTIVE 

630  ' 

640  FOR  I  =  1  TO  10 

650  HK$(I)  =  "SO" 

660  ACTIVE(I)  = 

=  0 

670  NEXT  I 

680  ' 

690  ' 

DISPLAY  FUNCTION  KEY  FUNC 

700  ' 

710  COLOR  0,7 

720  LOCATE  25,5 

730  PRINT  "  Fl 

ii 

740  LOCATE  25, 

19 

750  PRINT  "  F2 

ii 

760  LOCATE  25, 

29 

7  70  PRINT  "  F3 

ii 

780  LOCATE  25, 

40 

790  PRINT  "  F4 

ii 

800  LOCATE  25, 

52 

810  PRINT  "  F5 

ii 

820  LOCATE  25, 

64 

830  PRINT  "  F6 

ii 

840  COLOR  7,  0 

850  LOCATE  25, 

9 

860  PRINT  "SUSP/CONT" 

870  LOCATE  25, 

24 

880  PRINT  "HOOK" 

890  LOCATE  25, 

34 

900  PRINT  "ENTER" 

910  LOCATE  25, 

45 

920  PRINT  "MODIFY" 

930  LOCATE  25, 

57 

940  PRINT  "DELETE" 

950  LOCATE  25, 

69 

960  PRINT  "HALT" 
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APPENDIX  D:   LISTING   OF   HARNESS. BAS 


1000 
1010 
1020 
1030 
1040 
1050 
1060 
1070 
1080 
1090 
1100 
1110 
1120 
1130 
1140 
1150 
1160 
1170 
1180 
1190 
1200 
1210 
1220 
1230 
1240 
1250 
1260 
1270 
1280 
1290 
1300 
4999 


GET  WINDOW  PARAMETERS 
LEAD  XUL,  YUL,  XLR,  YLR,  CWIND 

DRAW  THE  WINDOW 
I0SUB  5000 

GET  LAND  PARAMETERS 
LEAD  CONTS 

DRAW  LAND  MASSES 
10SUB  8000 

GET  GRID  PARAMETERS 

READ  XYAX,  YTOP,  YBOTT,  YCOL 
READ  YXAX,  XLEFT ,  XRITE ,  XCOL 


'HOW  MANY  LAND  MASSES? 


DRAW  THE  GRID 


GOSUB  5200 


RUN  UPDATE  TESTS 


GOSUB  11000 


END 
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APPENDIX  E:      LISTING      OF      WINDOW. BAS 


5000 
5010 
5020 
5030 
5040 
5050 
5060 
5070 
5080 
5090 
5100 
5110 
5120 
5130 
5140 
5150 
5160 


DRAW      WINDOW      SUBROUTINE 


.'-   JU   .'-   -'- 


*  INPUTS:      XUL,    YUL   -    UPPER  LEFT-HAND  COORDINATES 

*  XLR,    YLR    -  LOWER  RIGHT-HAND  COORDINATES 

*  CWIND  -    COLOR  OF  WINDOW 
*v 

*  OUTPUT:      SOLID  WINDOW,    XLR  -   XUL  PIXELS  WIDE, 

*  YLR   -  YUL  PIXELS  DEEP,    COLOR  CWIND 


* 
* 


J.   JU   JL  -K.       J,       4 


.'-   -»-   .'-   JL   y- 


-'-   -'-   >•- 


LINE   (XUL,    YUL)    -    (XLR,   YLR),    CWIND,    BF 
RETURN 
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APPENDIX  F 


LISTING   OF   AXES.BAS 


5200 
5210 
5220 
5230 
5240 
5250 
5260 
5270 
5280 
5290 
5300 
5310 
5320 
5330 
5340 
5350 
5360 
5365 
5370 
5380 
5390 
5400 
5405 
5410 
5420 
5430 
5440 
5450 
5460 
5470 
5480 
5490 
5500 
5510 
5520 
5530 
5540 
5550 
5560 
5570 
5580 
5590 
5600 
5610 
5620 
5630 
5640 


'<  it   *  *  *  *        COORDINATE   AXES   SUBROUTINE   *  *  *  *  *  *  * 

INPUTS:   XYAX,  YTOP ,  YBOTT   -  VERTICAL  AXIS  COORDINATES 

YXAX,  XLEFT,  XRITE  -  HORIZONTAL  AXIS  COORDINATES 
XCOL,  YCOL         -  GRID  COLORS 

OUTPUT:   PROPERLY  SCALED  SET  OF  COORDINATE  AXES, 
OF  XCOL  AND  YCOL 


* 


* 
* 
* 
* 
* 


it    if    if    if    if    if    if    if 


«»-  »v  «*» 


if    if    if    if    it 


it    if    if    if    it    it    it 


HSCALE  =  (XRITE  -  XLEFT) /20 
VSCALE  =  HSCALE  *  .46 


•HORIZONTAL  SCALE  MULTIPLIER 
'VERTICAL  SCALE  MULTIPLIER, 
'FOR  PROPER  ASPECT  RATIO 


DRAW  VERTICAL  AXIS 


LINE  (XYAX-1,  YTOP)  -  (XYAX+1,  YBOTT),  CWIND,  BF 
LINE  (XYAX,  YTOP)  -  (XYAX,  YBOTT),  YCOL 


DRAW  HORIZONTAL  AXIS 


LINE  (XLEFT,  YXAX-1)  -  (XRITE,  YXAX+1),  CWIND,  BF 

LINE  (XLEFT,  YXAX)  -  (XRITE,  YXAX),  XCOL 
i 

'         DRAW  HORIZONTAL  SCALE  DIVISIONS,  LEFT 
i 

FOR  H  =  XYAX  TO  XLEFT  STEP  -HSCALE 

LINE  (H,  YXAX-2)  -  (H,  YXAX+2),  XCOL 

LINE  (H+l,  YXAX-2)  -  (H+l,  YXAX+2),  XCOL 

NEXT  H 
i 

'         DRAW  HORIZONTAL  SCALE  DIVISIONS,  RIGHT 
t 

FOR  H  =  XYAX  TO  XRITE  STEP  HSCALE 

LINE  (H,  YXAX-2)  -  (H,  YXAX+2),  XCOL 
LINE  (H+l,  YXAX-2)  -  (H+l,  YXAX+2),  XCOL 

NEXT  H 


DRAW  VERTICAL  SCALE  DIVISIONS,  UPPER 


FOR  V  =  YXAX  TO  YTOP  STEP  -VSCALE 

LINE  (XYAX-4,  V)  -  (XYAX+4 ,  V),  YCOL 

NEXT  V 
i 

'  DRAW  VERTICAL  SCALE  DIVISIONS,  LOWER 
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5650  FOR  V  =  YXAX  TO  YBOTT  STEP  VSCALE 

5660   LINE  (XYAX-4,  V)  -  (XYAX+4,  V),  YCOL 

5670  NEXT  V 

5680  * 

5690  RETURN 

5700  ' 

5710  ' 

5720  '  THIS  AXES  SUBROUTINE  IS  BASED  ON  THE  PROGRAM 

5730  '         9-2,  PAGE  9-15,  IN  THE  CONTINUING  EDUCATION 

5740  *  CORRESPONDENCE  COURSE  "COMPUTER  GRAPHICS", 

5750  '         WRITTEN  FOR  HEATHKIT/ ZENITH  BY 

5760  '  JAMES   C.   ADAMS 
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APPENDIX  G:   LISTING  OF   UPDATE. BAS 


6000 
6010 
6020 
6030 
6040 
6050 
6060 
6070 
6080 
6100 
6120 
6130 
6140 
6150 
6160 
6170 
6180 
6190 
6200 
6210 
6220 
6225 
6230 
6240 
6250 
6255 
6260 
6270 
6280 
6290 
6295 
6300 
6305 
6310 
6320 
6322 
6324 
6330 
6340 
6350 
6360 
6370 
6374 
6375 
6376 
6380 
6390 


**•  -'-   -*,   *>. 


t    UPDATE   TRACKS   SUBROUTINE 

*  INPUTS:   UPD  -   OF  TRACK  TO  UPDATE 

*  OUTPUT:   TRACK  UPD  IS  UPDATED 


.1   -'-   JL   -■-   *>,   .'- 


-*--<--'- 


*  *  it    i 


,v  *  ■*■ 


it    it    it    it       it    it    *  it    it    it    it    it    it    it    ii 


JU  ■*■  •'•  -■-  -'» 


PERFORM  ALL  LOOK-UPS  ONLY  ONCE 

UPDX  =  TX(UPD) 

UPDY  =  TY(UPD) 

UPDT$  =  HK$(UPD)  +  T$(UPD) 

UPDL$  =  L$(UPD) 

HORZUP  =  XINC(UPD) 

VERTUP  =  YINC(UPD) 

COLUP  =  TCOLOR(UPD) 
i 

IF  ACTIVE(UPD)  =  2  THEN  6375 

UPGND  =  POINT(UPDX+2,  UPDY+1 ) 

ON  UPGND+1  GOSUB  6520,  6530,  6540,  6550,  6560,  6570,  6580,  6590 

WANT$  =  C0L$  +  UPDT$:  ALS0$  =  C0L$  +  UPDL$ 


PSET  (UPDX,  UPDY),  UPGND 

DRAW  WANT$ 

PSET  (UPDX,  UPDY),  UPGND 

DRAW  ALS0$ 

DRAW  "SO" 
i 

IF  ACTIVE(UPD)  =  0  THEN  6490 

UPDX  =  UPDX  +  HORZUP 

UPDY  =  UPDY  +  VERTUP 

IF  UPDX<15  OR  UPDX>470  THEN  6482 

IF  UPDY<27  OR  UPDY>190  THEN  6482 
t 

UPGND  =  P0INT(UPDX+2,  UPDY+1) 
i 

IF  UPGND  <>  COLUP  THEN  6375 

IF  UPGND  <  2  THEN  COLUP  =  7  ELSE  COLUP 


•DRAW  OLD  SYMBOL  IN 
'REVERSE  COLOR 


'UPDATE  POSITION 


=  0 


'CHECK  BACKGROUND  COLOR 

OF  NEW  LOCATION 
'MAKE  SYMBOL  OPPOSITE 
'  OF  BACKGROUND 


ON  COLUP+l  GOSUB  6520,  6530,  6540,  6550,  6560,  6570,  6580,  6590 
WANT$  =  COL$  +  UPDT$:  ALS0$  =  C0L$  +  UPDL$ 


PSET  (UPDX,  UPDY),  COLUP 


'DRAW  NEW  SYMBOL 
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6400  DRAW  WANT$ 

6410  PSET  (UPDX,  UPDY) ,  COLUP 

6420  DRAW  ALSO$ 

6425  DRAW  "SO" 

6430  ' 

6440  TX(UPD)  =  UPDX 

6450  TY(UPD)  =  UPDY 

6460  ' 

6480  ' 

6482  ACTIVE(UPD)=0 

6490  RETURN 


'STORE  NEW  POSITION 


6500  ' 

6510  ' 

6520  C0L$ 

= 

"CO": 

RETURN 

6530  C0L$ 

= 

"CI": 

RETURN 

6540  C0L$ 

= 

"C2": 

RETURN 

6550  C0L$ 

= 

"C3": 

RETURN 

6560  C0L$ 

= 

"C4": 

RETURN 

6570  C0L$ 

= 

"C5": 

RETURN 

6580  C0L$ 

= 

"C6": 

RETURN 

6590  COL$ 

= 

"C7": 

RETURN 
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APPENDIX  H:   LISTING   OF   MOVE.BAS 


7000 

JL   JL   JL   JL   _'. 

*  • 

v    SYMBOL 

MOVEMENT   CALCULATOR    *  *  *   *  * 

7010 

JL 

* 

7020 

*   INPUTS 

:   1 

10VE 

-  TRACK  TO  CALCULATE 

FOR 

* 

7030 

* 

* 

7040 

*  OUTPUT 

m           •* 

ttNC,  YINC, 

SCALE  FACTOR  FOF 

l  SPEED 

* 

7050 

JL 

LEADER 

OF  EACH  ACTIVE  TRACK 

ARE 

* 

7060 

JL 

( 

:alculated  and  stored 

* 

7070 

JL 

* 

7080 

*\        •»    /»   1\        *» 

JL   . 

L   JL   JL   JL   JL 

\   /*    *\       7%       7*      * 

t  "k   "k   it  "k   *  Vf  &   i 

.   .'.   .'.   .•.   y.   . 

'?  *  *  * 

7090 

7100 

7110 

7130 

7140 

CALCULATE  INCREMENTS  BASED  ON  COURSE 

7150 

7160  ] 

;f 

CUS(MOVE) 

<  = 

5 

THEN 

7400 

7170  ] 

:f 

CUS(MOVE) 

<= 

22.5 

THEN 

7410 

7180  ] 

[F 

CUS(MOVE) 

<  = 

45 

THEN 

7420 

7190  ] 

[F 

CUS(MOVE) 

<= 

67.5 

THEN 

7430 

7200  ] 

LF 

CUS(MOVE) 

<  = 

85 

THEN 

7440 

7210  ] 

LF 

CUS(MOVE) 

<= 

95 

THEN 

7450 

7220  ] 

LF 

CUS(MOVE) 

<  = 

112.5 

THEN 

7460 

7230  ] 

LF 

CUS(MOVE) 

<  = 

135 

THEN 

7470 

7240  1 

LF 

CUS(MOVE) 

<  = 

157.5 

THEN 

7480 

7250  ] 

LF 

CUS(MOVE) 

<  = 

175 

THEN 

7490 

7260  ] 

LF 

CUS(MOVE) 

<  = 

185 

THEN 

7500 

7270  ] 

[F 

CUS(MOVE) 

<  = 

202.5 

THEN 

7510 

7280  ] 

LF 

CUS(MOVE) 

<  = 

225 

THEN 

7520 

7290  ] 

LF 

CUS(MOVE) 

<  = 

247.5 

THEN 

7530 

7300  ] 

[F 

CUS(MOVE) 

<  = 

265 

THEN 

7540 

7310  ] 

LF 

CUS(MOVE) 

<= 

275 

THEN 

7550 

7320  ] 

LF 

CUS(MOVE) 

<  = 

292.5 

THEN 

7560 

7330  ] 

LF 

CUS(MOVE) 

<  = 

315 

THEN 

7570 

7340  ] 

LF 

CUS(MOVE) 

<  = 

337.5 

THEN 

7580 

7350  ] 

LF 

CUS(MOVE) 

<  = 

355 

THEN 

7590 

7360 

7370 

i 

7400  3 

(INC (MOVE)  = 

8: 

YINC (MOVE) 

=  0:  L$(M0VE)  = 

LDR$(3):  ( 

50TO  7  600 

7410  3 

(INC(MOVE)  = 

-  7: 

YINC (MOVE) 

=  -3:  L$(MOVE)  = 

=  LDR$(2): 

GOTO  7600 

7420  : 

(INC (MOVE)  = 

5: 

YINC (MOVE) 

=  -5:  L$(MOVE)  = 

'  LDR$(2): 

GOTO  7600 

7430  3 

(INC  (MOVE)  = 

■  5: 

YINC (MOVE) 

=  -5:  L$(MOVE)  = 

=  LDR$(2): 

GOTO  7600 

7440  3 

(INC(MOVE)  = 

3: 

YINC(MOVE) 

=  -7:  L$(MOVE)  = 

'  LDR$(2): 

GOTO  7600 

7450  3 

(INC(MOVE)  = 

■  0: 

YINC (MOVE) 

=  -8:  L$(MOVE)  = 

=  LDR$(1): 

GOTO  7600 

7460  : 

(INC(MOVE)  = 

-3 

:  YINC(MOVE: 

)  =  -7:  L$(MOVE) 

=  LDR$(8) 

:  GOTO  7  600 

7470  : 

(INC(MOVE)  = 

'  -5 

:  YINC (MOVE] 

)  =  -5:  L$(MOVE) 

=  LDR$(8) 

:  GOTO  7600 

7480  3 

(INC(MOVE)  = 

-5 

:  YINC(MOVE" 

)  =  -5:  L$(MOVE) 

=  LDR$(8) 

:  GOTO  7600 
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7490  XINC(MOVE)  =  -7:  YINC(MOVE)  =  -3:  L$(M0VE) 

=  LDR$(8' 

:  GOTO  7600 

7500  XINC(MOVE)  =  -8:  YINC(MOVE)  =  0:  L$(M0VE) 

=  LDR$(7): 

GOTO 

7600 

7510  XINC(MOVE)  =  -7:  YINC(MOVE)  =  3:  L$(M0VE) 

=  LDR$(6): 

GOTO 

7600 

7520  XINC(MOVE)  =  -5:  YINC(MOVE)  =  5:  L$(MOVE) 

=  LDR$(6): 

GOTO 

7600 

7530  XINC(MOVE)  =  -5:  YINC(MOVE)  =  5:  L$(M0VE) 

=  LDR$(6): 

GOTO 

7600 

7540  XINC(MOVE)  =  -3:  YINC(MOVE)  =  7:  L$(M0VE) 

=  LDR$(6)- 

GOTO 

7600 

7550  XINC(MOVE)  =  0:  YINC(MOVE)  =  8:  L$(M0VE)  = 

LDR$(5) : 

GOTO 

7600 

7560  XINC(MOVE)  =  3:  YINC(MOVE)  =  7:  L$(MOVE)  - 

LDR$(4): 

GOTO 

7600 

7570  XINC(MOVE)  =  5:  YINC(MOVE)  =  5:  L$(M0VE)  = 

LDR$(4) : 

GOTO 

7600 

7580  XINC(MOVE)  =  5:  YINC(MOVE)  =  5:  L$(MOVE)  = 

LDR$(4): 

GOTO 

7600 

7590  XINC(MOVE)  =  7:  YINC(MOVE)  -  3:  L$(MOVE)  = 

LDR$(4): 

GOTO 

7600 

7595  XINC(MOVE)  =  8:  YINC(MOVE)  =  0:  L$(M0VE)  = 

LDR$(3) 

7600  ' 

7  610  '         CALCULATE  AMOUNT  OF  INCREMENT,  SPEED  LEADER 

7620  '         SCALE,  BASED  ON  SPEED 

7630  ' 

7640  IF  SPD(MOVE)  >=  100  THEN  7690 

7641    IF  SPD(MOVE)  <>  0  THEN  7650 

7642     XINC(MOVE)  =  0 

7643     YINC(MOVE)  =  0 

7644     L$(M0VE)  =  "" 

7645     GOTO  7770 

7650   XINC(MOVE)  =  INT(.5  *  XINC(MOVE)) 

7660   YINC(MOVE)  =  INT(.5  *  YINC(MOVE)) 

7670   L$(MOVE)  =  "S2"  +  L$(M0VE) 

7680   GOTO  7770 

7690  IF  SPD(MOVE)  <=  600  THEN  7770 

7700   XINC(MOVE)  =  INT (2  *  XINC(MOVE)) 

7710   YINC(MOVE)  =  INT(2  *  YINC(MOVE)) 

7720   L$(M0VE)  =  "S8"  +  L$(M0VE) 

7760  ' 

7770  RETURN 

7780  ' 
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APPENDIX  I:   LISTING  OF   LAND.BAS 


j.     ,v     J.  riDAU         T   »HFI         CTTRPnTTTTMIT  ■*■    -A-     -V     -.'-     -•-     ■*■     ■*•     * 


DRAW   LAND   SUBROUTINE 


*  INPUTS:   PTS  -  ARRAY  OF  #s  OF  BORDER  POINTS  * 

*  CONTS  -  #  OF  LAND  MASSES  * 

*  OUTPUT:   PLOTTED  LAND  MASSES,  IN  SPECIFIED  COLORS  * 

*  *  *  *  *  *  *  *  *  *  *  *  *   *  *  *  *  *  *  *  *  *  *    *  *  *  *  * 


8000 

8010 

8020 

8025 

8030 

8040 

8050 

8060 

8070 

8075  IF  CONTS  =  0  THEN  RETURN  'NO  LAND  MASSES,  NO  DRAW 

8080  ' 

8090  FOR  I  =  1  TO  CONTS 

8100   READ  PTS(I),  LCOL(I) 

8110  NEXT  I 

8120  ' 

8125  DIM  LAND1(PTS(1),  2),  LAND2(PTS(2) ,  2),  LAND3(PTS(3) ,  2) 

8130  FOR  ISLE  =  1  TO  PTS(l) 

8140   READ  LAND1(ISLE,  1),  LAND1(ISLE,  2) 

8150  NEXT  ISLE 

8160  ' 

8170  FOR  ISLE  =  1  TO  PTS(2) 

8180   READ  LAND2(ISLE,  1),  LAND2(ISLE,  2) 

8190  NEXT  ISLE 

8200  ' 

8210  FOR  ISLE  =  1  TO  PTS(3) 

8220   READ  LAND3( ISLE,  1),  LAND3(ISLE,  2) 

8230  NEXT  ISLE 

8240  ' 

8250  PSET  (LAND1(1,1),  LAND1(1,2)),  LCOL(l) 

8260  FOR  ISLE  =  2  TO  PTS(l) 

8270   LINE  -  (LAND1(ISLE,  1),  LAND1(ISLE,  2)),  LCOL(l) 

8280  NEXT  ISLE 

8290  ' 

8300  READ  CENTX,  CENTY 

8310  ' 

8320  PAINT  (CENTX,  CENTY),  LCOL(l),  LCOL(l) 

8330  ' 

8340  IF  PTS (2)  <  2  THEN  RETURN 

8350  ' 

8360  PSET  (LAND2(1,1),  LAND2(1,2)),  LCOL(2) 

8370  FOR  ISLE  =  2  TO  PTS(2) 

8380    LINE  -  (LAND2(ISLE,  1),  LAND2(ISLE,  2)),  LCOL(2) 

8390  NEXT  ISLE 

8400  ' 

8410  READ  CENTX,  CENTY 

8420  ' 
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8430  PAINT  (CENTX,  CENTY)  ,  LCOL(2),  LCOL(2) 

8440  ' 

8450  IF  PTS(3)  <  2  THEN  RETURN 

8460  ' 

8470  PSET  (LAND3(1,1),  LAND3(1,2)),  LC0L(3) 

8480  FOR  ISLE  =  2  TO  PTS(3) 

8490   LINE  -  (LAND3(ISLE,  1),  LAND3(ISLE,  2)),  LCOL(3) 

8500  NEXT  ISLE 

8510  ' 

8520  READ  CENTX,  CENTY 

8530  ' 

8540  PAINT  (CENTX,  CENTY),  LC0L(3),  LCOL(3) 

8550  ' 

8560  RETURN 
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APPENDIX  J:   LISTING  OF   DATA.BAS 


10000 
10010 
10020 
10030 
10040 
10050 
10060 
10070 
10080 
10090 
10100 
10110 
10120 
10130 
10140 
10150 
10160 
10170 
10180 
10190 
10200 
10210 
10220 
10230 
10235 
10240 
10250 
10260 
10270 
10275 
10280 
10290 
10300 


'Jrkitii'/ric'kic'k 


DATA 


«*  y»  **  /*  #\  /\  4%   /*  *»?»  **«»*» 


LCOL(2) 


140,  125,  135,  155, 
125 


134 


'   XUL,  YUL,  XLR,  YLR,  CWIND 

DATA   15,  27,  470,  190,  7 

'  CONTS 

DATA  2 

'  PTS(l),  LCOL(l),  PTS(2) 

DATA  8,  3 

DATA  5,  5 

1  BORDER  POINTS  FOR  LAND  MASS  ONE 

DATA  100,  125,  120,  150,  130, 

DATA  160,  127,  125,  125,  100, 

'  BORDER  POINTS  FOR  LAND  MASS  TWO 

DATA  240,  100,  270,  105,  290,  90,  265,  85,  240,  100 

'  BORDER  POINTS  FOR  DUMMY  LAND  MASS 

DATA  1,  1 

*  CENTER  OF  LAND  MASS  ONE 

DATA  120,  135 

'  CENTER  OF  LAND  MASS  TWO 

DATA  265,  95 

1  XYAX,  YTOP,  YBOTT,  YCOL 

DATA  157,  27,  190,  0 

'  YXAX,  XLEFT,  XRITE,  XCOL 

DATA  145,  15,  470,  0 

DATA  3 

'  TRACK(l),  CLASS$(1),  CUS(l),  SPD(l),  TCOLOR(l) 

DATA  "HOSTILE",  180,  35,  0,  420,  80 

'  TRACK(2),  CLASS$(2),  CUS(2),  SPD(2),  TCOLOR(2),  TX(2.),  TY(2) 

DATA  "FRIENDLY",  4,  135,  0,  50,  100 

'        TRACK  (3) 

DATA  "UNKNOWN",  110,  650,  0,  430,  170 

1        NUMBER  OF  MOVES  TO  TEST  UPDATING 

DATA  5 


TX(1),  TY(1) 
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APPENDIX  K:   LISTING   OF   TRACKING. BAS 


11000 
11010 
11020 
11030 
11040 
11050 
11060 
11070 
11080 
11090 
11100 
11110 
11120 
11125 
11130 
11135 
11136 
11140 
11150 
11160 
11165 
11170 
11175 
11180 
11190 
11200 
11210 
11220 
11225 
11230 
11235 
11240 
11250 
11255 
11260 
11270 
11280 
11300 
11310 
11320 
11330 
11340 
11350 
11360 
11370 
11380 


•JU   *F«   JU  A       -'-   »•- 


TEST   TRACKING   SUBROUTINE 


INPUTS:   TRACKS  -  #  OF  TEST  TRACKS 


'   *  OUTPUT:   SAMPLE  OF  TRACKS  BEING  UPDATED 


*  * 
it 

■k 


J-       J-       JL 


'  ^^^^^^^^^^JLJLJ^Jk^JLJLJbJL       .•«       JL       JL       JL       JL 

I 

READ  TRACKS 

IF  TRACKS  =  0  THEN  11200 
FOR  I  =  1  TO  TRACKS 

READ  CLASS$(I),  CUS(I),  SPD(I),  TCOLOR(I),  TX(I),  TY(I) 

UPD  =  I 

GOSUB  20000 

ACTIVE(I)  =  1 

IF  CLASS$(I)  =  "REF  PNT   "  THEN  ACTIVE(I)  =  2 

NEXT  I 
t 

t 

FOR  MOVE  =  1  TO  TRACKS 

GOSUB  7000 
NEXT  MOVE 


D0$  =  "" 
i 

WHILE  D0$  =  "" 

FOR  UPD   =  1  TO  TRACKS 

GOSUB  6000 

NEXT  UPD 

FOR  I  =  1  TO  2000 

D0$  =  INKEY$ 

IF  D0$=""  THEN  NEXT  I  ELSE  11280 

WEND 
i 

IF  D0$  <>  CHR$(27)  THEN  11200  ELSE  D02$  -  INKEY$ 
• 

IF  D02$  =  "P"  THEN  GOSUB  12000 

IF  D02$  =  "S"  THEN  GOSUB  12100 

IF  D02$  =  "T"  THEN  GOSUB  12200 

IF  D02$  =  "U"  THEN  GOSUB  12500 

IF  D02$  =  "V"  THEN  GOSUB  12800 

IF  D02$  =  "W"  THEN  GOSUB  13500 
t 

GOTO  11200 
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APPENDIX  L:   LISTING  OF  KEYS.BAS 


12000 
12010 
12020 
12030 
12040 
12050 
12060 
12062 
12064 
12066 
12068 
12070 
12072 
12074 
12080 
12085 
12090 
12100 
12110 
12120 
12130 
12140 
12150 
12160 
12170 
12180 
12190 
12200 
12210 
12220 
12230 
12240 
12250 
12252 
12254 
12256 
12258 
12259 
12260 
12270 
12275 
12276 
12280 
12282 
12284 
12286 


Jc    ic    Jc 


JU   JU   *»- 


FUNCTION  KEY   SUBROUTINES 


'  7.  %  7.  7.  7.  HALT  PROGRAM 

'  FUNCTION  KEY  F6 

i 

CLS 

KEY  1,  "LIST  " 

KEY  2,  "RUN"  +  CHR$(13)  +  CHR$(10) 

KEY  3,  "LOAD"  +  CHR$(34) 

KEY  4,  "SAVE"  +  CHR$(34) 
i 

KEY  5,  "CONT"  +  CHR$(13)  +  CHR$(10) 

KEY  6,  "PRINT  " 

END 

RETURN 

i 


1  7.  7„  7.  7.  7o   SUSPEND/CONTINUE   PROGRAM 
1  FUNCTION  KEY  Fl 


GO$  =  "" 
i 

WHILE  GO$  =  "" 

GO$  =  INKEY$ 

WEND 
i 

RETURN 

'  7o  7,  7o  7.  %     HOOK  TRACK 

'  FUNCTION  KEY  F2 


LOCATE  2,  10 
i 

IF  HOOK  =  0  THEN  12270 

ACTIVE (HOOK)  =  0 

UPD  =  HOOK 

GOSUB  6000 

ACTIVE(HOOK)  =  1 

HK$(HOOK)  =  "SO" 
i 

INPUT  "TRACK  TO  HOOK:  ";HOOK 

LOCATE  2,  10 

PRINT  " 
i 

ACTIVE(HOOK)  =  0 
UPD  =  HOOK 
GOSUB  6000 
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12288 
12290 
12300 
12310 
12320 
12330 
12340 
12350 
12360 
12370 
12380 
12390 
12400 
12410 
12420 
12500 
12510 
12520 
12530 
12540 
12550 
12560 
12570 
12571 
12572 
12573 
12574 
12575 
12576 
12580 
12590 
12595 
12596 
12600 
12610 
12615 
12616 
12620 
12630 
12635 
12636 
12640 
12650 
12655 
12656 
12660 
12670 
12680 
12690 
12700 
12702 


ACTIVE (HOOK)  =  1 

HK$(H00K)  =  "S8" 
i 

LOCATE  6,  6  2 

PRINT  "TRACK  NO.  "  ;H00K 

LOCATE  7,  6  2 

PRINT  "CLASS   "; CLASS $ (HOOK) 

LOCATE  8,  6  2 

PRINT  "COURSE   ";CUS(HOOK) 

LOCATE  9,  62 

PRINT  "SPEED     ";SPD(HOOK) 
■ 

i 

RETURN 
i 

1  78  7o  7o  7.  70   ENTER  NEW  TRACK 

1  FUNCTION  KEY  F3 

i 

TRACKS  =  TRACKS  +  1 

MOVE  =  TRACKS 

i 

LOCATE  2,  10 

INPUT  "ENTER  CLASS    "; CLASS $( TRACKS) 

SIZECL  =  LEN(CLASS$ (TRACKS)) 

IF  SIZECL  <  9  THEN  ADD  =  9  -  SIZECL 

IF  ADD=0  THEN  1257  5 

FOR  I  =  1  TO  ADD: CLASS $ (TRACKS)  =  CLASS $ (TRACKS)  +  "  ":NEXT  I 

LOCATE  2,  10 


PRINT  ' 
LOCATE 
INPUT  ' 
LOCATE 
PRINT  ' 
LOCATE 
INPUT  ' 
LOCATE 
PRINT  ' 
LOCATE 
INPUT  ' 
LOCATE 
PRINT  ' 
LOCATE 
INPUT  ' 
LOCATE 
PRINT  ' 
LOCATE 
INPUT  ' 
LOCATE 
PRINT  ' 


2,  10 

ENTER  COURSE  " ;CUS (TRACKS) 

2,  10 


2,  10 

ENTER  SPEED 
2,  10 


;SPD( TRACKS) 


2,  10 

ENTER  GRID  X   ";TX(TRACKS) 

2,  10 

it 

2,  10 

ENTER  GRID  Y   ";TY(TRACKS) 

2,  10 

n 

2,  10 

TRACK  COLOR   " ;TC0L0R( TRACKS) 

2,  10 


IF  CLASS$(MOVE)  =  "REF  PNT   "  THEN  ACTIVE(MOVE)  =  2 
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12705  GOSUB  20000 

12710  GOSUB  7000 

12712  UPD  =  MOVE 

12715  GOSUB  20000 

12716  HK$(UPD)  =  "SO":  ACTIVE(UPD)  =  1 


12717 

GOSUB  6000 

12720 

t 

12730 

RETURN 

12740 

i 

12750 

i 

12800 

'  7o  7o  7.  7o  7.  MODIFY  TRACK 

12810 

1                FUNCTION  KEY  : 

12820 

i 

12830 

IF  HOOK  =   0  THEN  12840 

12832 

ACTIVE (HOOK)  =  0 

12834 

UPD  =  HOOK 

12836 

GOSUB  6000 

12838  ACTIVE(HOOK)  -  1 

12839 

HK$(H00K)  =  "SO" 

12840 

LOCATE  2,  10 

12850 

INPUT  "TRACK  TO  MODIFY:  ";HOOK 

12855 

LOCATE  2,  10 

12856 

PRINT  " 

12860 

i 

12870 

GOSUB  12300 

12872 

ACTIVE (HOOK)  =  0 

12874 

UPD  =  HOOK 

12876 

GOSUB  6000 

12878  ACTIVE(HOOK)  =  1 

12879 

HK$(HOOK)  =  "SO" 

12880 

i 

12890 

LOCATE  2,  10 

12900 

INPUT  "IS  CLASS  OK  ";A$ 

12910 

IF  A$  <>  "Y"  THEN  LOCATE  2,  40 

12915 

LOCATE  2,  10 

12916 

PRINT  " 

12920 

i 

12930 

LOCATE  2,  10 

12940 

INPUT  "IS  COURSE  OK  ";A$ 

12950 

IF  A$  <>  "Y"  THEN  LOCATE  2,  40 

12955 

LOCATE  2,  10 

12956 

PRINT  " 

12960 

i 

12970 

LOCATE  2,  10 

12980 

INPUT  "IS  SPEED  OK  ";A$ 

12990 

IF  A$  <>  "Y"  THEN  LOCATE  2,  40 

12995 

LOCATE  2,  10 

12996 

PRINT  " 

13000 

t 

13010 

LOCATE  2,  10 

INPUT  "NEW  CLASS  : " ;CLASS$(H00K) 


INPUT  "NEW  COURSE :";CUS (HOOK) 


INPUT  "NEW  SPEED:  ";SPD(HOOK) 


13020  INPUT  "IS  COLOR  OK  ";A$ 
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13030 
13035 
13036 
13040 
13050 
13060 
13070 
13075 
13076 
13080 
13090 
13100 
13110 
13115 
13116 
13120 
13130 
13140 
13145 
13147 
13150 
13160 
13170 
13500 
13510 
13520 
13530 
13540 
13550 
13560 
13565 
13566 
13570 
13580 


IF  A$  <>  "Y"  THEN  LOCATE  2 ,  40  : 

LOCATE  2,  10 

PRINT  " 
i 

LOCATE  2,  10 

INPUT  "IS  GRID  X  OK  ";A$ 

IF  A$  <>  "Y"  THEN  LOCATE  2 ,  40  : 

LOCATE  2,  10 

PRINT  " 
i 

LOCATE  2,  10 

INPUT  "IS  GRID  Y  OK  ";A$ 

IF  A$  <>  "Y"  THEN  LOCATE  2 ,  40  : 

LOCATE  2,  10 

PRINT  " 
i 

MOVE  =  HOOK 
GOSUB  7000 
UPD  =  HOOK 
GOSUB  6000 

RETURN 
i 

1  7o  7o  %  7.  7.  DELETE  A  TRACK 

1  ■  FUNCTION  KEY  F5 

i 

LOCATE  2,  10 

INPUT  "TRACK  TO  DELETE:  ";DEL 


ACTIVE(DEL)  =  0 

LOCATE  2,  10 

PRINT  " 
i 


INPUT  "NEW  COLOR:  " ;TCOL0R(H0OK) 


INPUT  "NEW  GRID  X:  ";TX(H00K) 


INPUT  "NEW  GRID  Y:  ";TY(H00K) 


RETURN 
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APPENDIX  M:   LISTING  OF   MATCH. BAS 


20000  '  *  *  *  *  *   *  *   SYMBOL  ASSIGNMENT   *  *  *  *  *  *  * 

20010  *  *  * 

20020  '  *   INPUTS:   UPD  -  TRACK  TO  HAVE  SYMBOL  ASSIGNED  * 

20030  '  *  * 

20040  '  *  OUTPUT:   TRACK(UPD)  IS  ASSIGNED  A  SYMBOL      * 

20050  '  *  THAT  MATCHES  ITS  CLASSIFICATION      * 

20060  '  *  * 

20070  '  *  *  *  -a-  *  *  *  *  *  *  *  v?  *******  *  *  *  *  *  * 

20080  ' 

20090  ' 

20100  IF  CLASS$(UPD)  =  "HOSTILE   "  THEN  T$(UPD)  =  SYM$(4):  GOTO  20240 

20110  ' 

20120  IF  CLASS$(UPD)  =  "HOST  SURF"  THEN  T$(UPD)  =  SYM$(6):  GOTO  20240 

20130  ' 

20140  IF  CLASS$(UPD)  =  "UNKNOWN   "  THEN  T$(UPD)  =  SYM$(3):  GOTO  20240 

20150  ' 

20160  IF  CLASS$(UPD)  =  "UNK  AIR   "  THEN  T$(UPD)  =  SYM$(5):  GOTO  20240 

20170  ' 

20180  IF  CLASS$(UPD)  =  "FIGHTER   "  THEN  T$(UPD)  =  SYM$(2):  GOTO  20240 

20190  ' 

20200  IF  CLASS$(UPD)  =  "SURVEILL  "  THEN  T$(UPD)  =  SYM$(1):  GOTO  20240 

20210  ' 

20220  IF  CLASS$(UPD)  =  "REF  PNT   "  THEN  T$(UPD)  =  SYM$(7) 

20230  ' 

20240  RETURN 

20250  ' 
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APPENDIX  N:   USER'S  MANUAL  FOR  DISPLAY  SIMULATOR 

A.   HOW  TO  USE  THIS  SIMULATOR 

The  minimum  system   configuration   requirements  for  this 
NTDS  display  simulator  are  as  follows: 


H/Z-100  or  compatible  computer 
128K  RAM  memory 
1  DS/DD  5  1/4"  disk  drive 
Z-DOS  1.25  operating  system 
ZBASIC  interpreter  or  compiler 
the  file  NEWEST. BAS 

or 
the  subroutine  files  making  up  NEWEST. BAS,  which  are 

—  HEADER. BAS 

—  INIT.BAS 

—  HARNESS. BAS 

—  WINDOW. BAS 

—  AXES. BAS 

—  LAND. BAS 

—  MOVE. BAS 

—  UPDATE. BAS 

—  TRACKING. BAS 

—  DATA. BAS   or   DATAl.BAS 

—  MATCH. BAS 

—  KEYS. BAS 


B.   GETTING  STARTED 

"Boot  up"  the  computer  system  under  the  Z-DOS  operating 
system.  After  getting  the  system  prompt  ensure  that  the 
default  disk  drive  (if  there  are  two  or  more)  contains  the 
file  ZBASIC.COM  (the  ZBASIC  interpreter),  unless  using  the 
compiled  version.  If  working  with  the  compiled  version, 
follow  the  instructions  for  compiling  and  running  a  ZBASIC 
program  that  came  with  the  compiler  being  used. 
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1.  This  step  is  for  users  without  the  file  NEWEST. BAS. 
If  that  file  is  present,  skip  to  step  B.2. 

Type  the  command  "ZBASIC".  This  will  load  the  ZBASIC 
interpreter.  When  it  displays  its  prompt,  load  any  one  of 
the  subroutine  files.  Then  type  MERGE  "filename"  for  each 
of  the  other  files,  one  by  one.  Once  they  are  all  merged 
type  RUN  (If  any  error  messages  are  displayed  when 
attempting  to  do  this,  one  or  more  of  the  files  may  not  be 
stored  properly.  In  order  to  store  them  properly  they  will 
have  to  be  loaded  when  there  is  no  other  program  stored  in 
memory,  and  saved  with  the  command  SAVE  "filename",  A.  This 
saves  them  in  an  ASCII  format,  which  allows  them  to  be 
merged  with  other  files). 

2.  Load  NEWEST.   Type  RUN. 

C.   INTERACTING  WITH  THE  SIMULATOR 

While  the  simulator  is  running  it  accepts  user  input 
through  the  use  of  the  special  function  keys.  The  special 
function  key  menu  is  displayed  on  line  25  of  the  monn.or, 
below  the  NTDS  display. 

The  Suspend/Continue  key  is  a  double  action  key  —  to 
suspend  the  automatic  updating  of  tracks  (and  all  other 
system  functions)  depress  the  Fl  key.  To  resume  system 
operation  depress  it  again.  When  it  is  depressed  for  the 
"continue"  function  all  tracks  will  be  updated. 
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The  Hook  key  (F2)  allows  the  display  of  the  track 
parameters  for  one  of  the  tracks  in  the  system.  When  it  is 
depressed  the  system  will  request  an  input  at  the  top  of  the 
screen.  It  will  prompt  the  user  to  input  the  track  number 
of  the  track  to  hook.  The  input  must  be  a  number  between  1 
and  10,  or  an  error  will  result.  If  the  number  is  the 
number  of  an  active  track  that  track  will  have  its  symbol 
enlarged  as  long  as  it  is  hooked,  and  its  parameters 
displayed  to  the  right  of  the  NTDS  display  area. 

The  Enter  key  (F3)  allows  a  new  track  to  be  entered. 
The  user  will  be  prompted  for  inputs  at  the  top  of  the 
screen.  For  CLASS$,  input  the  classification  of  the  new 
track  (no  more  than  nine  characters,  please).  If  the 
classification  does  not  match  one  the  system  recognizes,  the 
speed  leader  only  will  be  displayed  for  the  new  track.  The 
currently  recognized  inputs  are:  "HOSTILE",  "FIGHTER", 
"UNKNOWN",  "HOST  SURF",  "REF  PNT",  "SURVEILL" ,  and  "UNK 
AIR".  The  CUS  (course)  should  be  a  number  between  0  and 
360,  representing  degrees  true.  Speed  (SPD)  should  be  a 
positive  number,  greater  than  or  equal  to  zero,  representing 
speed  in  knots.  Grid  X  is  the  X  coordinate  of  the  track,  in 
terms  of  the  display.  It  should  be  a  number  in  the  range  of 
15-470.  Likewise  Grid  Y  is  a  display  coordinate,  and  ranges 
from  27-190.  Numbers  other  than  these  will  work,  if  they 
are  within  the  range  of  the  pixels  of  the  display.  The 
Update  module   tests   for   the   coordinates   of   the   track, 
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however,  and  the  track  will  not  move  if  placed  outside  the 
display  window.  Track  Color  should  be  a  number  between  0-7. 
On  the  monochrome  systems  this  will  not  matter  unless  it  is 
0  or  7 — 'On  color  systems  these  numbers  correspond  to  the 
colors  listed  in  the  User's  Manual. 

The  F4  key,  Modify,  will  go  through  the  same  track 
parameters  that  were  just  discussed  for  the  F3  key..  It  will 
first  ask  which  track  to  modify,  and  the  track  number  must 
be  input.  The  system  then  hooks  that  track,  and  goes 
through  each  track  parameter  asking  if  it  is  OK.  The  user 
should  input  a  "Y"  if  the  parameter  is  fine,  anything  else 
if  it  is  not.  If  the  response  is  other  than  "Y"  the  user 
will  be  requested  to  input  the  correct  value  for  that 
parameter,  and  the  hooked  track  will  be  modified 
accordingly. 

The  Delete  key,  F5,  asks  the  user  to  provide  a  track 
number,  and  the  track  number  input  will  be  deleted.  Upon 
the  next  update  of  the  system  it  will  no  longer  appear  on 
the  screen. 

The  Halt  key,  F6,  provides  a  gracious  exit  from  the 
display  simulator  system.  When  it  is  depressed  it  restores 
the  special  function  keys  to  their  ZBASIC  settings,  clears 
the  screen,  and  returns  the  ZBASIC  interpreter  prompt. 
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D.   MODIFYING  THE  INITIAL  DISPLAY 

The  initial  display,  in  its  entirety,  is  determined  from 
the  DATA  module.  By  modifying  the  DATA  module,  or  creating 
a  new  one,  and  re-merging  it  with  the  system,  a  new  initial 
display  may  be  created.  There  is  a  caution  here:  if  a  new 
(or  modified)  DATA  module  is  used,  the  line  numbers  must 
match  all  those  of  the  old  module,  or  the  unused  old  numbers 
must  be  deleted,  to  prevent  erroneous  assignments. 

The  data  should  be  entered  in  the  order  of  Figure  N.l, 
within  the  ranges  and  for  the  purposes  stated  below. 

The  first  five  data  values  relate  to  the  window.  The 
first  two  of  them,  XUL  and  YUL,  are  the  X  and  Y  coordinates 
of  the  upper  left-hand  corner  of  the  display  window, 
respectively.  The  X  value  should  fall  between  0-480,  and 
the  Y  value  between  20-212.  The  same  range  restrictions 
apply  to  the  XLR  and  YLR  values,  which  are  the  coordinates 
for  the  lower  right-hand  corner  of  the  window.  The  color  of 
the  box,  a  number  between  zero  and  7,  is  given  by  CWIND. 

The  window  parameters  are  followed  by  CONTS,  the  number 
of  land  masses  (or  special  areas)  the  initial  display  will 
contain.  The  current  system  limitation  is  for  a  maximum  of 
3,  and  this  number  should  not  be  less  than  zero.  If  CONTS 
is  zero,  the  next  data  value  to  be  read  in  is  XYAX. 
Otherwise  there  are  CONTS  number  of  entries  of  the  variables 
specified  within  the  square  brackets  ( [  ] ) . 
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For  each  'continent1  there  should  be  a  value  pair  (PTS, 
LCOL) .  The  PTS  is  the  number  of  points  (  (x,y)  coordinate 
pairs  )  that  specify  the  border  of  the  land   area,   LCOL   is 

XUL 

YUL 

XLR 

YLR 

CWIND 

CONTS 
[  -     PTS,  LCOL  ]  -  CONTS  TIMES 

[  -     XI,  Yl,  X2,  Y2,  ...  XN,  YN  ]  -  CONTS  TIMES 
[  -     CENTX,  CENTY  ]  -  CONTS  TIMES 

XYAX 

YTOP 

YBOTT 

YCOL 

YXAX 

XLEFT 

XRITE 

XCOL 

TRACKS 
[  -     CLASS$,  CUS,  SPD,  TCOLOR,  TX,  TY  ]  -  TRACKS  TIMES 

MOVES 

Figure  N.l   Order  of  Data  Entry 

the  color  of  that  piece  of  land.   After  the  PTS,  LCOL  pairs 
(one  pair  for  each  land  area  to  be  input)  there  are  CONTS 
lists  of  ordered  pairs,  Xm,  Ym,  each  pair  representing  a 
border  point  of  the  land  mass.   The  final  subscript,  N, 
should  match  the  PTS  number  for  each  particular  land  mass, 
and  XN,  YN  should  match  XI,  Yl  to  ensure  that  the  land  mass 
will  be  painted  properly.   After  the  list  of  border  points 
is  read  in,  an  interior  point,  CENTX,  CENTY,  is  read  in. 
This  should  be  a  point  not  on  the  border  but  within  in. 
This  is  the  point  that  determines  the  area  of  the  screen 
that  will  be  painted  in  LCOL  color. 
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The  following  four  data  values  specify  the  vertical  grid 
parameters,  and  the  four  after  that  the  horizontal  grid. 
The  XYAX  value  should  fall  somewhere  between  the  XUL  and  XLR 
values  read  in  earlier.  It  is  the  horizontal,  or  X, 
coordinate  of  the  Y  axis.  YTOP  and  YBOTTOM  are  the  top  and 
bottom  of  the  Y-axis,  and  should  match  YUL  and  YLR 
respectively,  if  the  grid  is  to  be  from  the  top  of  the 
window  to  the  bottom.  The  grid's  color  is  determined  by 
YCOL,  which  should  be  between  0-7. 

The  vertical  grid  parameters  are  followed  by  those  for 
the  horizontal  grid,  and  they  are  of  the  same  form.  The 
first,  YXAX,  is  the  vertical  location  of  the  horizontal  grid 
line,  and  should  be  between  YUL  and  YLR.  The  XLEFT  and 
XRITE  specify  the  ends  of  the  horizontal  grid,  and  should 
match  XUL  and  XLR  for  a  full-window  grid.  The  grid  color  is 
independent  of  the  vertical  grid  color,  and  is  specified  by 
a  number  0-7  for  XCOL. 

If  the  initial  display  is  to  have  any  test  tracks  prior 
to  user  input  the  number  of  them  is  read  in  through  the 
parameter  TRACKS.  This  number  should  have  a  value  between 
zero  and  ten,  the  system  currently  being  limited  to  ten 
tracks.  If  TRACKS  is  zero  the  next  data  value  is  MOVES. 
Otherwise,  the  data  following  TRACKS  is  sets  of  parameters 
for  the  initial  tracks. 

CLASS$  is  the  classification  of  each  test  track,  and 
should  be  a  character  string  surrounded  by  quotes,  no  longer 
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than  nine  characters  (excluding  the  quotation  marks).  The 
currently  recognized  classifications  are  "HOSTILE",  "HOST 
SURF",  "UNK  AIR",  "REF  PNT",  "FIGHTER",  "SURVEILL"  and 
"UNKNOWN".  Any  classification  other  than  these  will  result 
in  a  symb  1  which  consists  only  of  a  speed  leader  for  the 
track. 

CUS  and  SPD  are  the  course  and  speed  of  the  track.  They 
should  be  positive  or  zero.  The  course  is  in  degrees  true 
(0-360)  and  the  speed  is  in  knots(0-?).  TCOLOR  is  the  track 
color,  and  should  again  be  a  0-7  number. 

The  TX  and  TY  are  the  grid  coordinates  of  the  track's 
initial  position.  They  are  pixel  coordinates  on  the  screen. 
TX  should  be  between  XUL  and  XLR,  T  b^twe.n  YUL  and  YLR. 
If  they  are  not  one  of  two  things  will  happen.  If  they  are 
outside  the  range  of  the  window  but  within  the  range  of  the 
screen  they  will  be  drawn  on  the  screen  in  the  specified 
position,  and  not  updated.  If  they  are  outside  the  range  of 
the  screen  (0-639  for  x,  0-224  for  y)  an  error  will  result, 
and  the  system  will  be  exited. 

The  value  of  MOVES  should  be  zero  if  TRACKS  is  zero.  It 
represents  the  number  of  automatic  times  the  system  will 
update  the  tracks  if  there  is  no  user  input.  Actually,  this 
is  a  hold-over  from  an  earlier  version  of  the  system.  It 
may  be  used  if  the  system  is  modified — otherwise  it  will  be 
ignored. 
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E.   UNDERSTANDING  THE  CODE 

Following  is  a  line  by  line  explanation  of  the  code. 
The  subsections  correspond  to  the  subroutines  that  make  up 
the  display  simulator  system.  Each  subsection  is  titled 
according  to  its  subroutine.  The  code  may  be  examined  by 
following,  in  order,  Appendix  A,  which  is  a  listing  of  the 
assembled  subroutines,  or  by  following  the  appropriate 
Appendix  for  each  subroutine. 

1.  Header 

We  begin  with  a  header,  identifying  the  program  and 
clearing  the  screen.   These  statements  are  lines  10-90. 

2.  Init 

The  next  section  of  code,  "INITIALIZATION  AND 
TABLES"  (lines  100-960)  performs  several  housekeeping  chores 
to  set  up  the  prototype.  Line  130  sets  the  array  subscript 
lower  bound,  and  lines  150-170  allocate  memory  for  the 
necessary  arrays.  The  symbol  and  speed  leader  tables  (SYM$ 
and  LDR$ )  are  initialized  in  lines  180-440. 

The  variable  TRACKS  is  initialized  to  zero.  Later 
in  the  program  it  is  read  from  a  DATA  statement,  to 
determine  how  many  tracks  the  system  starts  with  prior  to 
user  input.  Whenever  a  track  is  added,  TRACKS  is  incre- 
mented. If  it  exceeds  ten,  the  dimension  of  the  parts  of 
the  TRACK  record  (see  Figure  3.1),  a  subscript  out  of  range 
error  will  result.   The  prototype  does  no  'garbage 
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collection',  as  such,  and  flags  inactive  tracks  with  a  value 
of  zero  in  the  ACTIVE  field. 

Line  510  initializes  the  elements  of  the  PTS  array 
to  one.  This  is  necessary  because  of  the  lack  of  dynamic 
memory  allocation  in  ZBASIC.  The  elements  of  the  PTS  array 
are  used  in  the  Land  module  to  dimension  arrays,  and  must  be 
greater  than  or  equal  to  one. 

The  special  function  keys  are  initialized  in  lines 
530-600.  This  prototype  was  developed  with  a  ZBASIC  inter- 
preter, ZBASIC,  under  Z-DOS  version  1.25.  In  that 
environment  the  special  function  keys  are  pre-set  to  provide 
ZBASIC  commands.  These  lines  re-set  them  to  generate  their 
normal  escape  sequences  when  depressed. 

The  HK$  and  ACTIVE  fields  of  each  track  are 
initialized  in  lines  620-670.  This  prototype  was  developed 
for  color  and/or  monochrome  use.  The  current  Zenith 
monitors  at  NPS  are  monochrome.  For  that  reason  we  elected 
to  indicate  a  hooked  track  by  enlarging  its  symbol.  The  HK$ 
field  will  always  be  drawn  as  part  of  the  symbol.  If  the 
track  is  not  hooked  it  will  be  scale  zero  ("SO"),  for  normal 
size.  For  hooked  tracks  it  is  changed  to  "S8",  for  double 
size.  The  ACTIVE  field  is  primarily  used  to  determine  which 
tracks  are  active.  Reference  points  require  special 
treatment  in  this  prototype,  for  efficiency.  A  more 
detailed  explanation  is  with  the  Update  module.   A  value  of 
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2   in   the   ACTIVE   field   indicates   that   the   track   is  a 
reference  point. 

The  final  chore  performed  by  the  Init  module  is  the 
display  of  the  function  keys  menu.  Lines  690-960  provide 
the  user  with  reverse  video  labels  of  the  active  function 
keys,  and  normal  video  display  of  their  purposes  on  line  25 
of  the  display.  This  places  the  menu  close  to  the  keys 
involved  and  out  of  the  main  display  area. 
3 .   Harness 

The  test  harness,  or  Harness  module,  follows  in 
lines  1000-4999.  It  grew  as  the  prototype  was  developed. 
The  final  line,  4999,  which  is  an  END  statement,  is  no 
longer  necessary,  but  was  prior  to  the  installation  of  user 
interaction  as  a  feature.  During  development  and  testing 
all  inputs  were  through  program  lines  and  DATA  statements. 
This  may  be  a  good  point  at  which  to  mention  that  there  are 
some  unnecessary  lines  remaining,  many  unused  line  numbers, 
and  some  sections  of  code  where  line  numbers  are  too  close 
together . 

The  presence  of  unnecessary  lines  does  not  adversely 
affect  the  performance  of  the  prototype.  Some  of  them  are 
left  in  to  allow  follow-on  researchers  to  see  some  history 
of  the  thought  process  and  development  procedures  used 
before.  Most  of  them  are  present  to  allow  for  spacing  and 
readability  of  the  code,  and  are  left  in  for  those  reasons. 
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In  most  cases  the  line  numbers  are  spaced  by  tens. 
This  allows  for  the  insertion  of  several  lines  wherever 
necessary  during  the  ongoing  development  of  the  system.  In 
some  cases  they  are  closer  together,  demonstrating  the  prior 
development  and  debugging.  There  are  wide  gaps  in  some 
sections  of  code,  illustrating  the  modular  development 
process.  It  is  particularly  important  when  writing  files 
which  will  be  merged  to  attempt  to  assign  line  numbers  which 
will  not  risk  duplication. 

The  Harness  module  requires  little  explanation.  It 
reads  DATA  statements  to  obtain  parameters,  calls  on 
subroutines  to  make  use  of  the  parameters  to  draw  static 
portions  of  the  display,  and  transfers  control  to  the 
Tracking  module  in  line  1280. 

4.  Window 

The  Window  module,  lines  5000-5160,  is  also  self- 
explanatory.  It  is  written  in  general  terms,  and  may  be 
used  to  draw  any  size  box,  anywhere  on  the  screen,  in  any 
color  and  for  any  purpose. 

5 .  Axes 

Most  of  the  modules  are  written  to  be  useful 
elsewhere.  The  Axes  module  is  no  exception.  We  could  have 
made  use  of  the  previous  module,  Window,  and  re-defined  what 
have  been  labelled  the  window  parameters,  since  Axes  also 
draws  boxes.  This  is  just  one  example  of  extra  code  being 
written,    and    trickiness    avoided,    for    clarity   and 
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readability.  This  feature,  abundant  code  and  prolific 
variable  creation  rather  than  re-using  the  same  variable 
names  for  different  purposes,  also  enhances  maintainability. 

Lines  5320-5330  ensure  that  aspect  ratio  is 
maintained  when  the  two  axes  are  scaled.  Line  5365  draws  a 
box  one  pixel  wider  on  each  side  than  the  vertical  axis  line 
of  the  window's  color.  This  enables  the  axis  to  cross  any 
color  land  mass  without  getting  lost.  Line  5405  does  the 
same  thing  for  the  horizontal  axis. 
6.   Update 

The  Update  module  is,  in  many  ways,  the  heart  of  the 
system.  It  is  the  module  that  re-positions  the  track 
symbols  periodically,  draws  and  erases  them,  and  checks  to 
see  if  they  fall  within  the  window  limits. 

The  first  thing  Update  does  is  look  up  all  array 
variables  that  are  referenced  frequently  in  the  module. 
This  saves  time  when  each  variable  is  used.  It  is  much 
faster  for  the  interpreter  to  look  up  the  copy  in  the  local 
simple  variable  than  to  compute  the  address  from  an  array 
index.  Lines  6150-6210  do  the  copying  of  array  variables 
into  local  simple  variables. 

Line  6230  samples  a  background  point  at  the  current 
symbol  position.  A  common  method  of  erasing  in  computer 
graphics,  and  the  one  employed  here,  is  to  re-draw  the 
symbol  in  the  color  of  its  background.  Based  on  the  color 
of   the  local  background  one  of  eight  subroutines  determines 
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the  proper  color  for  the  string  COL$ .  The  reason  the 
statement  using  UPGND  +  1  is  because  the  colors  are  from  0- 
7,  but  the  ON  <exp>  GOSUB  statement  requires  a  number  equal 
to  or  greater  than  one  to  branch. 

The  string  WANT$  is  then  composed  of  the  color  and 
the  symbol,  ALSO$  is  composed  of  the  color  and  the  speed 
leader  (both  of  these  being  the  color  of  the  background  in 
this  case,  to  perform  an  erasure),  then  each  string  is  drawn 
at  the  current  symbol  position. 

In  line  6260  the  symbol  is  located  at  its  current 
position.  Line  6270  draws  the  symbol,  line  6280  relocates 
at  symbol  center  and  line  6290  draws  the  speed  leader.  The 
scale  is  returned  to  normal  in  line  6295. 

If  the  symbol  is  inactive  (ACTIVE  =  0)  this  is  all 
that  is  required  and  line  6305  directs  program  flow  to  the 
RETURN  statement.  For  active  symbols  lines  6310-6320  update 
the  position  of  symbol  center  and  program  flow  continues. 

Line  6340  samples  the  background  at  the  updated 
symbol  position.  If  there  is  no  conflict  logic  similar  to 
that  just  completed  for  the  erasure,  using  COLUP  (the 
current  symbol  color)  rather  than  UPGND  (background  color) 
draws  the  re-located  symbol  in  lines  6375-6425.  If  there  is 
a  conflict  line  6370  makes  the  symbol  white  for  dark 
backgrounds  and  black  for  light  backgrounds. 

Lines  6440-6450  store  the  updated  symbol  position  in 
the  TX  and  TY  fields  of  the  track  record.   Line  6490  returns 
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to   the   calling   routine.     Each   of   the   lines  6520-6590 
contains   two  statements,  constituting  an  entire  subroutine. 
These  are  the  subroutines  called  upon  to  set  COL$,  which   is 
used  to  determine  the  color  the  symbol  will  be  drawn  in. 
7 .   Move 

The  Move  module  determines  how  many  pixels  in  each 
direction  a  symbol  will  move  when  it  is  updated  and  which 
speed  leader  will  be  assigned  to  a  track,  based  on  track 
course  and  speed.  Lines  7160-7350  branch  to  the  appropriate 
line  number  based  on  the  course,  dividing  the  full  circle  of 
directions  (courses  0-360  degrees  true)  into  20  zones. 
Lines  7400-7590  are  the  lines  branched  to,  only  one  of  which 
will  be  executed.  They  make  the  assignment  of  incremental 
values  of  change  in  the  x  and  y  direction  and  assign  one  of 
the  eight  speed  leaders  from  the  speed  leader  table,  then 
branch  to  7600.  Together  these  lines  (7160-7590)  form  one 
giant  case  statement. 

Line  7640  branches  to  7690  if  the  target  is  not  a 
slow  speed  track.  For  slow  speed  tracks  that  do  have  motion 
line  7641  branches  to  7650.  Lines  7642-7645  handle  tracks 
with  no  motion,  ensuring  no  incremental  movement  and  no 
speed  leader.  For  slow  speed  tracks  that  do  move  lines 
7650-7680  reduce  the  incremental  movement  and  scale  the 
speed  leader  down. 

Medium  speed  tracks,  treated  as  the  norm,  are 
handled  by  the  branch   from   line   7690-7770,  7770  being  the 
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RETURN.  Lines  7700-7720  handle  high  speed  tracks  by 
increasing  the  incremental  movement  and  scaling  up  the  speed 
leader . 

8 .   Land 

This  is  the  module  that  draws  the  land  masses.  It 
currently  provides  for  only  three  land  masses.  Because 
ZBASIC  has  no  dynamic  memory  allocation  the  DIM  (dimension) 
statements  cannot  be  executed  more  than  once  or  an  error 
results.  For  more  land  masses  to  be  introduced  to  the 
system  they  must  be  described  by  the  same  number  (or  fewer) 
points  than  one  of  the  first  three  and  one  of  the  three  land 
arrays  re-used,  or  more  land  arrays  must  be  added  to  this 
module  in  the  DIM  statement (s) .  The  latter  solution  is  the 
easiest  to  implement,  and  will  be  the  easiest  for  others  to 
follow  later  on.  That  is  why  it  was  chosen  here,  rather 
than  simply  dimensioning  one  array  large  enough  to  handle 
any  probable  number  of  points. 

Line  8075  guards  against  execution  if  there  are  no 
land  masses  to  draw.  If  there  are  land  masses  the  variable 
CONTS  contains  the  number,  and  is  used  as  an  index  in  the 
loop  of  lines  8090-8110,  which  reads  in  the  numbers  of 
points  of  each  of  the  masses  and  their  color.  Line  8125 
sets  aside  memory  for  the  arrays,  as  mentioned  earlier. 

This  module  has  been  designed  for  zero  or  three. 
The  intention  was  to  make  the  logic  clear,  and  also  to 
provide  loops  for  all  three  so   that   only  data   statements 
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would  need  to  be  changed  if  any  number  0-3  were  input.  That 
is  why  there  are  three  loops,  lines  8130-8150,  8170-8190  and 
8210-8230  which  read  in  the  points  describing  the  land 
masses.  If  there  are  fewer  than  three  at  least  one  dummy 
point  must  be  in  the  data  statements  for  each  of  the  unused 
arrays . 

Lines  8250-8280  draw  the  first  land  mass  (if  there 
were  none  to  draw  line  8075  would  prevent  the  branch  to 
here).  Line  8300  reads  the  coordinates  of  an  interior  point 
for  the  first  land  mass,  and  line  8320  paints  it. 

If  there  is  only  one  land  mass  line  8340  executes 
the  RETURN.  Otherwise  lines  8360-8430  perform  the  same 
functions  for  land  mass  two  as  8250-8320  did  for  land  mass 
one.  Lines  8450-8540  perform  a  similar  test  and  conditional 
execution  of  land  mass  three  function.  If  there  were  three 
land  masses  line  8560  executes  the  RETURN,  otherwise  it 
would  have  already  been  executed. 
9.   Data 

We  have  already  gone  over  the  data  format.  The  Data 
module  follows  it,  interspersing  the  data  with  comments  for 
clarity.  It  is  recommended  that  users  follow  the  same 
procedure.  It  makes  corrective  maintenance  and  enhancement 
much  easier.  Another  design  philosophy  embodied  here  and 
encouraged  is  the  matching  of  one  data  statement  to  one  read 
statement.  Code  could  be  reduced  by  combining,  for  example, 
the   data   in  lines  10080  and  10120-10140.   Instead  we  opted 
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to  keep  the  data  on   separate  lines  matching  read  statements 
in  the  program.   This  procedure  reduces  debugging  time  (it's 
easy   to   create   mis-matched  data/read  pairs)  and  makes  the 
module  more  readable. 
10.  Tracking 

This  module  performs  the  automatic  system  updating 
of  tracks  and  monitoring  for  user  input.  It  is  the  driver 
program,  in  essence,  whereas  the  Harness  module  is  the 
initialization  driver. 

Line  11080  determines  if  there  are  any  initial 
tracks  in  the  system.  If  not  line  11100  branches  to  11200, 
skipping  lines  11110-11140,  which  read  in  the  initial  tracks 
if  there  are  any. 

For  initial  tracks  lines  11165-11175  calculate  the 
appropriate  incremental  movements  and  assign  speed  leaders, 
through  the  use  of  the  Move  module. 

•  Line  11200  initializes  the  DO$  variable  to  an  empty 
string.  DO$  is  used  to  tell  the  system  what  to  do  if  there 
is  user  input. 

Lines  11220-11260  drive  the  system  until  there  is 
user  input.  All  tracks  are  automatically  updated  in  lines 
11225-11235,  the  user  is  given  a  chance  for  input  during  a 
pause  between  updates  in  lines  11240-11255.  The  constant 
2000  in  line  11240  determines  the  length  of  time  between 
updates  when  there  is  no  user  input.  If  it  is  reduced, 
shortening  the  delay,  a  reasonable  minimum  would  probably  be 
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500.  If  the  delay  is  too  short  the  user  reaction  may  be  too 
slow  to  input  a  selection,  resulting  in  at  least  one  more 
update  than  desired.  The  motions  of  the  tracks  may  also 
appear  too  jerky  and/or  rapid  if  there  is  not  sufficient 
delay  between  updates.  When  the  system  detects  that  the 
user  has  depressed  a  key  the  program  branches  to  11280. 

Line  11280  reverts  to  the  initialization  in  line 
11200  and  repeats  the  process  if  the  key  struck  was  not  a 
special  function  key,  by  checking  for  the  first  character  to 
be  an  "ESCape"  (CHR$(27).  If  a  special  function  key  was 
struck  lines  11310  to  11360  branch  to  the  appropriate 
routine  to  handle  the  request.  Line  11380  reverts  to 
initialization  of  DO$  and  repeats  the  update/delay  process 
if  the  key  was  not  a  pre-defined  function  key,  or  upon 
completion  of  the  service  of  the  request. 
11.  Keys 

This  module  defines  the  special  function  key 
routines.  Keys  F1-F6  are  currently  defined,  more  could 
easily  be  added.  They  should  be  initialized  in  the  Init 
module,  branches  to  their  routines  provided  for  in  the 
Tracking  module,  and  their  routines  defined  in  this  one. 

Lines  12000-12085  handle  the  request  for  a  halt. 
The  screen  is  cleared  and  the  function  keys  are  restored 
before  the  END  statement  is  executed.  The  RETURN  statement 
is  not  really  necessary.  Actually  only  the  END  statement  is 
needed  here,  but  it   is   good   programming  practice  to  clear 
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the  screen  when  finishing  a  graphics  routine,  as  well  as 
restoring  functions  keys  defined.     The  RETURN  statement  is 
included  for  similar  reasons,  since  this  is  a  subroutine. 

Lines  12100-12190  perform  the  suspend/continue 
function,  by  simply  waiting  for  another  keyboard  input  co 
continue . 

The  hook  track  function  is  in  lines  12200-12420. 
The  locate  statements  ensure  that  messages  and  input 
requests  appear  at  the  top  of  the  screen.  Lines  12250-12259 
check  to  see  if  there  is  already  a  track  hooked,  and  unhook 
one  if  one  is  hooked. 

Line  12270  requests  the  input  of  the  track  to  hook, 
lines  12275-12276  clear  the  request  from  the  screen  when  the 
requested  input  has  been  provided.  The  track  input  as  the 
one  to  hook  is  hooked  in  lines  12282-12290.  After  it  has 
been  hooked  and  its  symbol  enlarged  (the  way  a  hooked  track 
is  displayed)  lines  12310-12380  display  its  parameters  to 
the  right  of  the  display  window. 

Lines  12500-12750  perform  the  enter  new  track 
function.  First  the  number  of  tracks  is  incremented  in 
lines  12530-12540.  Then  lines  12560-12690  request  for  each 
of  the  user  inputs  and  clear  the  requests  when  the  input  has 
been  made  (lines  12571-12574  ensure  that  the  classification 
will  be  exactly  nine  characters  in  length  for  symbol 
assignment) . 
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After  track  parameter  input  lines  12705-12717 
perform  necessary  calculations  and  matching  to  provide  the 
rest  of  the  track  parameters  and  display  the  new  track. 

12.  Match 

This  routine  simply  matches  the  CLASS$  of  a  track 
(classification)  to  its  appropriate  symbol.  Only  the  line 
which  finds  a  string  match  will  be  executed,  and  the  RETURN. 
If  there  is  no  match  no  symbol  will  be  assigned,  and  only 
the  speed  leader  will  be  displayed.  This  distinguishes 
unidentified  tracks  (which  may  be  unconfirmed,  bogus,  or 
whatever)  from  tracks  known  to  exist  but  unclassified 
( UNKNOWN ) . 

F.   CROSS-REFERENCE 

The  following  cross-reference  of  variables  is  provided 
as  an  aid  to  modifying  the  code  in  further  development.  It 
is  for  the  version  of  the  code  listed  in  Appendix  A,  the 
first  and  un-numbered  version. 


NAME 


PURPOSE 


LOCATIONS 


CLASS$( ) 


CUS(  ) 


classification 
of  track 


track's  course 


INIT,  TRACKING, 
KEYS,  MATCH, 
DATA 

INIT,  MOVE, 
TRACKING,  KEYS, 
DATA 
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NAME 


PURPOSE 


LOCATIONS 


SPD(  ) 

TCOLOR( ) 

TX() 

TY(  ) 

XINC( ) 

YINC( ) 

T$() 

L$() 

SYM$( ) 
LDR$( ) 

PTS(  ) 


track's  speed 


track  color 


track  x  coord 


track  y  coord 


horizontal 
movement 


vertical 
movement 


track  symbol 


track  speed 
leader 

generic  symbol 

generic  speed 
leader 

number  of  points 
defining  land  mass 


INIT,  MOVE, 
TRACKING,  KEYS, 
DATA 

INIT,  UPDATE, 
TRACKING,  KEYS, 
DATA 

INIT,  UPDATE, 
TRACKING,  KEYS, 
DATA 

INIT,  UPDATE, 
TRACKING,  KEYS, 
DATA 

INIT,  UPDATE, 
TRACKING,  KEYS, 
MOVE,  DATA 

INIT,  UPDATE, 
TRACKING,  KEYS, 
MOVE,  DATA 

INIT,  UPDATE, 
MATCH 

INIT,  UPDATE, 
MOVE 

INIT,  MATCH 

INIT,  MOVE 


INIT,  LAND,  DATA 


LCOL( ) 

land  color 

INIT, 

LAND,  D 

HK$() 

scale  to  draw  track 

INIT, 
KEYS 

UPDATE, 

ACTIVE ( ) 

state  of  track 

INIT, 
KEYS 

UPDATE, 

TRACKS 

number  of  tracks 

INIT, 

TRACKIN 

DATA,  KEYS 
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NAME 


PURPOSE 


LOCATIONS 


generic  loop 
counter 


INIT,  LAND, 
TRACKING,  KEYS 


XUL 


x  coordinate 
upper  left-hand 
corner  of  window 


HARNESS,  WINDOW, 
DATA 


YUL 


y  coordinate 
upper  left-hand 
corner  of  window 


HARNESS,  WINDOW, 
DATA 


XLR 


x  coordinate 
lower  right-hand 
corner  of  window 


HARNESS,  WINDOW, 
DATA 


YLR 


y  coordinate 
lower  right-hand 
corner  of  window 


HARNESS,  WINDOW, 
DATA 


CWIND 


CONTS 


window  color 


#  of  land  masses 


HARNESS,  WINDOW, 
AXES,  DATA 

HARNESS,  LAND, 
DATA 


XYAX 


x  coordinate 
Y-axis 


HARNESS,  AXES, 
DATA 


YTOP 


y  coordinate 
Y-axis  top 


HARNESS,  AXES, 
DATA 


YBOTT 


y  coordinate 
Y-axis  bottom 


HARNESS,  AXES, 
DATA 


YCOL 


Y-axis  color 


HARNESS,  AXES, 
DATA 


YXAX 


y  coordinate 
X-axis 


HARNESS,  AXES, 
DATA 


XLEFT 


x  coordinate 
X-axis  left 


HARNESS,  AXES, 
DATA 


XRITE 


XCOL 


x  coordinate 
X-axis  right 

X-axis  color 


HARNESS,  AXES, 
DATA 

HARNESS,  AXES, 
DATA 
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NAME 

HSCALE 

VSCALE 

H 

V 

UPDX 

UPDY 

UPDT$ 
UPDL$ 
HORZUP 

VERTUP 

COLUP 

UPGND 

COL$ 

WANT$ 

ALSO$ 

UPD 

LANDK  ,  ) 
LAND2( , ) 
LAND3( , ) 
ISLE 
CENTX 


PURPOSE 

LOCATIONS 

horizontal  scale 

AXES 

vertical  scale 

AXES 

loop  counter 

AXES 

loop  counter 

AXES 

x  coordinate 

UPDATE 

symbol  center 

y  coordinate 

UPDATE 

symbol  center 

symbol 

UPDATE 

speed  leader 

UPDATE 

horizontal 

UPDATE 

increment 

vertical 

UPDATE 

increment 

symbol  color 

UPDATE 

pixel  color 

UPDATE 

color  string 

UPDATE 

symbol  string 

UPDATE 

speed  leader  string 

UPDATE 

loop  counter 

UPDATE,  KEYS, 

TRACKING 

land  point 

land  point 

land  point 

loop  counter 

x  coordinate 
land  point 


LAND,  DATA 
LAND,  DATA 
LAND,  DATA 
LAND 
LAND,  DATA 
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NAME 

CENTY 

MOVE 

DO$ 

D02$ 

GO$ 

HOOK 

SIZECL 

A$ 

DEL 


PURPOSE 

LOCATIONS 

y  coordinate 

LAND ,  DATA 

land  point 

loop  counter 

TRACKING,  DATA, 

MOVE 

user  input 

TRACKING 

user  input 

TRACKING 

user  input 

KEYS 

hooked  track 

KEYS 

indicator 

length  of  CLASS$ 

KEYS 

user  input 

KEYS 

delete  track 

KEYS 

indicator 
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APPENDIX  0:   LISTING  OF  TEST  10. ASM 


TITLE  --  TEST  OF  FILLING  SCREEN  WITH  SYMBOL 

5 

P_STACK  SEGMENT  STACK 

DW      100H  DUP  (OFH) 
STK_TP  LABEL   WORD 
P  STACK  ENDS 


P  DATA 

SEGMENT 

SYMBOL 

DB 

OOOOOOOOB, 

OOOOOOOOB, 

OllllllOB 

DB 

00000000B, 

OOOOOOOOB, 

OllOOllOB 

DB 

OOOOOOOOB, 

OOOOOOOOB, 

OllOOllOB 

DB 

OOOOOOOOB, 

OOOOOOOOB, 

OllOOllOB 

DB 

OOOOOOOOB, 

OOOOOOOOB, 

OllOOllOB 

DB 

OOOOOOOOB, 

OOOOOOOOB, 

OllOOllOB 

DB 

OOOOOOOOB, 

OOOOOOOOB, 

OllOOllOB 

DB 

OOOOOOOOB, 

OOOOOOOOB, 

OllOOllOB 

DB 

OOOOOOOOB, 

OOOOOOOOB, 

OllllllOB 

SHAPE 

DB 
DB 
DB 
DB 
DB 
DB 
DB 
DB 
DB 

OllllllOB 
OllOOllOB 
OllOOllOB 
OllOOllOB 
OllOOllOB 
OllOOllOB 
OllOOllOB 
OllOOllOB 
OllllllOB 

TIME 

DB 

'00:00:00. 

00',  13,  10 

,  •$• 

TEN 

DB 

10 

DATA1 

DB 

16  DUP  (OBH) 

DATA  2 

DW 

8  DUP  (OBOH) 

P  DATA 

ENDS 

INCLUDE  PARM.DEF 
INCLUDE  DOS_FUNC.MAC 

> 

P_CODE   SEGMENT 

ASSUME   CS:P  CODE,  DS:P  DATA,  SS:P  STACK 


START:   MOV     AX,  P_STACK 
MOV     SS,  AX 
MOV     SP,  OFFSET  STK  TP 


PUSH    DS 
SUB     AX, 
PUSH    AX 


;set  up  SS  through  AX 

;set  up  SP 

;save  for  far  return 
;ensure  0  offset  for  far  rtn 
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MOV 

AX, 

P  DATA 

MOV 

DS, 

AX 

SUB 

AX, 

AX 

IN 

AL, 

IO_PORT 

PUSH 

AX 

;set  up  DS  through  AX 


;zero  AX,  to  save  10  port 

;status 

; save  status 


CALL 


CLS 


PUSH 

CX 

PUSH 

DX 

CALL 

TIMER 

POP 

DX 

POP 

CX 

MOV 

AL,  78H 

OUT 

10  PORT,  AL 

MOV 

SI,  0 

SUB 

BP,  BP 

SUB 

AX,  AX 

MOV 

AL,  SYMBOL [SI 

MOV 

BH,  L  COUNT 

MOV 

BP,  LINE 

NEG 

BP 

;clear  the  screen 


; save  registers,  then 
;call  the  timer  routine 

;restore  the  registers 


;prepare  10  port 

;set  up  symbol  part  counter 

;zero  BP,  for  offset 

;zero  AX,  for  symbol 

; top  scan-line  of  symbol 

;loop  counter  for  loop  L 

; start  BP  negative,  to 

; bring  it  to  0  at  beginning 

;of  loop 


outer  loop  (L)  --  for  L=l  to  L_C0UNT  do 

begin 

fill  line  (L)  with  symbol 
end 


L00P_L:  ADD 
MOV 


BP,  LINE 
CL,  I  COUNT 


;move  offset  to  next  line 
;set  loop  I  counter 


second  loop  (I)  --  for  1=  1  to  I_C0UNT  do 

begin 

write  (symbol)  @  line  L,  position  I 
end 


; reset  scanline  counter 
;get  top  scan-line 
; symbol  shape,  for  clearing 
;space  with  inverse 


third  loop  (J)  --  for  J=l  to  J_C0UNT  do 
begin 

write(symbol ,  scanline(J) 
end 


1  I:  MOV 

DI,  0 

MOV 

AL,  SYMBOL [SI] 

MOV 

AH,  SHAPE [DI] 

NOT 

AH 
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LOOP  J:  PUSH 

AX 

MOV 

AX,  B  PLANE 

MOV 

ES,  AX 

POP 

AX 

MOV 

BL,  K  COUNT 

;save  symbol,  use  AX  to 
;reset  ES  to  blue  plane 

; restore  symbol  to  AL 
;set  counter  for  loop  K 


inner  loop  (K) 


LOOP_K:  AND 
OR 
DEC 
CMP 
JLE 
PUSH 
MOV 
ADD 
MOV 
POP 
INC 
MOV 
JMP 

K_DONE:  INC 
CMP 
JGE 
ADD 
INC 
MOV 
MOV 
NOT 
JMP 

» 

J_DONE:  DEC 
CMP 
JLE 
MOV 
SUB 

INC 
JMP 

> 

I_DONE:  DEC 
CMP 
JLE 


for  K=l  to  K_COUNT  do 
begin 

negate  symbol 

AND  symbol  with  plane  (K) 

negate  symbol 

OR  symbol  with  plane  (K) 
end 


ES:[BP],  AH 

ES: [BP] ,  AL 

BL 

BL,  0 

K_DONE 

AX 

AX,  ES 

AX,  PLANE 

ES,  AX 

AX 

SI 

AL,  SYMBOL [SI] 

LOOPJC 

DI 

DI,  J_COUNT 

J_DONE 

BP,  VERT 

SI 

AL,  SYMBOL [SI] 

AH,  SHAPE [DI] 

AH 

LOOP_J 

CL 

CL,  0 
I_DONE 
SI,  0 
BP,  LINE 

BP 
LOOP_I 

BH 

BH,  0 
L  DONE 


AND  shape  inv.  with  plane  (K) 
OR  symbol  with  plane  (K) 
count  loop  K  iterations 
loop  K  done? 

Yes,  go  to  end  of  loop  K 
No,  save  symbol,  use  AX 
to  modify  ES  for  next 
color  plane 

restore  symbol  in  AL 
move  to  next  symbol  part 
get  next  symbol  part 
repeat  loop  K 

count  loop  J  iterations 
loop  J  done? 

Yes,  go  to  end  of  loop  J 
No,  move  to  next  scan-line 
get  next  symbol  part 
next  scan-line  of  symbol 
next  scan-line  of  shape 

repeat  loop  J 

count  loop  I  iterations 

loop  I  done? 

Yes,  go  to  end  of  loop  I 

back  to  first  part  of  symbol 

No,  move  to  start  of  symbol 

just  done,  then 

move  to  right  one  byte 

repeat  loop  I 

count  loop  L  iterations 

loop  L  done? 

Yes,  go  to  end  of  loop  L 
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SUB 

BP,  XJLINE 

MOV 

SI,  0 

JMP 

LOOP_L 

5 

L  DONE: 

PUSH 

CX 

PUSH 

DX 

CALL 

TIMER 

POP 

DX 

POP 

CX 

POP 

AX 

• 
> 

OUT 

IO_PORT,  AL 

EXIT 

PROC 
RET 

FAR 

EXIT 

ENDP 

;No,  move  to  start  of 
;last  character,  then 
;reset  symbol  part  counter 
;repeat  Loop  L 

;save  registers,  and 
;call  timer 

;restore  registers 

jrestore  10  port  status 


INCLUDE  CLS.SUB 
INCLUDE  TIMER. SUB 
INCLUDE  BOX. SUB 


P_C0DE   ENDS 
END 


START 
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APPENDIX  P:   LISTING  OF  TEST  8. ASM 


TITLE  --  EXPERIMENT  8  --  TEST  BOX  SUBROUTINE 


P_STK 

SEGMENT 

STACK 

DW 

100H  DUP  (00H) 

STK  TP 

LABEL 

WORD 

P_STK 

ENDS 

P  DATA 

SEGMENT 

TIME 

DB 

'00:00:00.00' , 

TEN 

DB 

10 

DB 

20H  DUP  (?) 

P  DATA 

ENDS 

INCLUDE  PARM.DEF 
INCLUDE  DOS_FUNC.MAC 

P_CODE   SEGMENT 

ASSUME   CS:P_CODE,  DS:P_DATA,  SS:P_STK 

START:   MOV     AX,  P_STK 
MOV     SS,  AX 
MOV     SP,  OFFSET  STK  TP 


PUSH 

DS 

SUB 

AX, 

AX 

PUSH 

AX 

MOV 

AX, 

P  DATA 

MOV 

DS, 

AX 

SUB 

AX, 

AX 

IN 

AL, 

IO_PORT 

PUSH 

AX 

save  10  port  status 


CALL 


CLS 


;clear  the  screen 


PUSH 

CX 

PUSH 

DX 

CALL 

TIMER 

POP 

DX 

POP 

CX 

MOV 

BH,  Y  START 

MOV 

AH,  Y  STOP 

MOV 

BL,  X  START 

MOV 

AL,  X  STOP 

;vertical  start  Line 
;vertical  stop  line 
jhorizontal  start  column 
;horizontal  stop  column 
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MOV 
MOV 

CALL 


CL,  COLOR 
CH,  OFFH 

BOX  F 


MOV 

BH,  Y  START 

MOV 

BL,  GRIDX  START 

MOV 

AH,  Y  STOP 

MOV 

AL,  GRIDX  STOP 

MOV 

CL,  G  COLOR 

MOV 

CH,  OFOH 

CALL 

BOX_F 

» 

CMP 

CL,  0 

JE 

X  AXIS 

MOV 

CH,  OFOH 

CALL 

BOX_F 

X_AXIS : 

MOV 

BH,  GRIDY  START 

MOV 

BL,  X  START 

MOV 

AH,  GRIDY  STOP 

MOV 

AL,  X  STOP 

MOV 

CL,  G  COLOR 

MOV 

CH,  OOH 

CALL 

BOX  F 

5 

CMP 

CL,  0 

JE 

OVER 

MOV 

CH,  OFFH 

CALL 

BOX_F 

> 

OVER: 

PUSH 

CX 

PUSH 

DX 

CALL 

TIMER 

POP 

DX 

POP 

CX 

POP 

AX 

OUT 

IO_PORT,  AL 

EXIT 

PROC 
RET 

FAR 

EXIT 

ENDP 

5 

INCLUDE 

BOX. SUB 

INCLUDE 

CLS.SUB 

INCLUDE 

TIMER. SUB 

> 

P  CODE 

ENDS 

END 

START 

; COLOR  box 
;solid  pixel  line 

;draw  box 
;draw  Y-axis 


; to  blank  out  space 


;if  grid  black, 
;it  is  already  drawn 
;half-byte  width 
;actually  draw  Y-axis 

;draw  X-axis 


;to  blank  out  space 


;if  grid  black, 
;it  is  already  drawn 
;solid  pixel  line 
jactually  draw  X-axis 


;restore  10  control  port 
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APPENDIX  Q:   LISTING   OF   TIMER. SUB 

this  is  a  subroutine  which  gets  and  converts  the  time, 
then  displays  it 

INPUTS:  none 

OUTPUTS:  the  time  is  displayed  on  the  screen 

FLAGS:  none 

REGISTERS:  none 

TIMER:  GETJTIME 

CONVERT  CH,  TEN,  TIME 
CONVERT  CL,  TEN,  TIME[3] 
CONVERT  DH,  TEN,  TIME[6] 
CONVERT  DL,  TEN,  TIME[9] 
DISPLAY  TIME 
RET 

end  of  timer  subroutine 
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APPENDIX  R:   LISTING  OF  BOX. SUB 

;  wa-ohaeqls  eh  topx  p  whiqt§uhihost  osueplraipo  posp  hi  ebs  wuossl 

5 

COMMENT  * 
INPUT:   BH  =  vertical  line  to  start  box  on  (0  -  23) 

BL  =  horizontal  column  to  start  box  on  (0  -  79) 

AH  =  vertical  line  to  stop  box  on  (1  -  24) 

AL  =  horizontal  column  to  stop  box  on  (1  -  80) 

NOTE:   if  AX  <  BX  an  error  will  result 

10  control  port  needs  to  be  saved  prior  to  calling  this 
subroutine 

OUTPUT:   generates  a  colored  box  on  the  screen 

FLAGS:   none  returned 

REGISTERS:  used  as  noted  above,  preserved 


B0X_F : 

PUSH 

AX 

PUSH 

BX 

PUSH 

CX 

PUSH 

DX 

PUSH 

DI 

PUSH 

SI 

PUSH 

BP 

PUSH 

DS 

5 

SUB 

DX,  DX 

MOV 

DH,  BH 

SHL 

DX,  1 

SHL 

DX,  1 

SHL 

DX,  1 

MOV 

DL,  BL 

MOV 

SI,  DX 

» 

SUB 

AL,  BL 

MOV 

DL,  AL 

5 

SUB 

AH,  BH 

MOV 

DH,  AH 

» 

CMP 

CL,  4 

JGE 

GREEN 

CMP 

CL,  2 

save  all  registers  used 


;zero  DX 

;get  start  line 

; convert  to  necessary  offset 


;rest  of  start  offset 
;starting  offset 

;how  many  bytes  across 
;DL  < horizontal  count 

;how  many  lines  down 
;DH  < vertical  count 

;does  color  include  green? 

;Yes ,  go  to  green 

;No,  does  it  include  red? 


123 


JGE 

RED 

JCXZ 

BLACK 

MOV 

AX,  0C000H 

MOV 

DS,  AX 

MOV 

AL,  38H 

JMP 

PREP 

5 

RED: 

MOV 

AX,  ODOOOH 

MOV 

DS,  AX 

SUB 

CL,  2 

JNZ 

MAGNTA 

MOV 

AL,  68H 

JMP 

PREP 

> 

MAGNTA: 

MOV 

AL,  28H 

JMP 

PREP 

5 

GREEN: 

MOV 

AX,  OEOOOH 

MOV 

DS,  AX 

SUB 

CL,  4 

JNZ 

CYAN 

MOV 

AL,  58H 

JMP 

PREP 

5 

CYAN: 

CMP 

CL,  1 

JNE 

YELLOW 

MOV 

AL,  18H 

JMP 

PREP 

5 

YELLOW : 

SUB 

CL,  2 

JNZ 

WHITE 

MOV 

AL,  48H 

JMP 

PREP 

WHITE: 

MOV 

AX,  OCOOOH 

MOV 

DS,  AX 

MOV 

AL,  08H 

JMP 

PREP 

5 

BLACK: 

MOV 

AX,  OCOOOH 

MOV 

DS,  AX 

MOV 

AL,  78H 

5 

PREP : 

OUT 

10  port,  a: 

MOV 

AL,  CH 

SUB 

CX,  CX 

MOV 

CL,  DL 

XOR 

BP,  BP 

MOV 

DL,  DH 

XOR 

DH,  DH 

MOV 

BP,  DX 

;Yes,  go  to  red 

;if  CL=0,  handle  black 

;No,  handle  blue 


;handle  red,  magenta 

; is  color  red? 
;No,  go  to  magenta 


;handle  green,  cyan,  yellow, 

;and  white 

;is  color  green? 

;No,  check  for  cyan 

;Yes,  handle  green 


;is  color  cyan? 
;No,  try  yellow 
;Yes,  handle  cyan 


;is  color  yellow? 
;No,  must  be  white 
;Yes,  handle  yellow 


;horizontal  count 


;vertical  count 
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MOV 

DI,  128 

PUSH 

SI 

PUSH 

CX 

> 

LUPE: 

MOV 

[SI] ,  AL 

MOV 

ES: [SI]  ,  AL 

INC 

SI 

LOOP 

LUPE 

> 

DEC 

BP 

JZ 

FINISH 

POP 

CX 

POP 

SI 

ADD 

SI,  DI 

PUSH 

SI 

PUSH 

CX 

JMP 

LUPE 

FINISH: 

POP 

CX 

POP 

SI 

POP 

DS 

POP 

BP 

POP 

SI 

POP 

DI 

POP 

DX 

POP 

CX 

POP 

BX 

POP 

AX 

;line  spacing 


RET 


end  of  subroutine  to  draw  box 
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APPENDIX  S:   LISTING  OF   CLS.SUB 


subroutine  to  clear  the  screen,  ZENITH 
INPUT:  none 
OUTPUT:  none 
FLAGS:  none 
REGISTERS:  none 
CLS :     PUSH    AX 


DELA: 


IN 

AL,  0D8H 

PUSH 

AX 

MOV 

AL,  OFH 

OUT 

0D8H,  AL 

IN 

AL,  ODBH 

AND 

AL,  0F7H 

OUT 

ODBH,  AL 

IN 

AL,  0D9H 

AND 

AL,  0F7H 

OUT 

0D9H,  AL 

MOV 

CX,  6680 

NOP 

LOOP 

DELA 

IN 

AL,  0D9H 

OR 

AL,  08H 

OUT 

0D9H,  AL 

POP 

AX 

OUT 

0D8H,  AL 

POP 

AX 

RET 

; save  register  used 

; prepare  to  save  10  control 
;port  status,  and  save  it 

; blank  the  screen 


;SET  =  0 


activate  CLRSCRN 


;wait 


; de-activate  CLRSCRN 

;restore  10  control  port 
; restore  register 


;  end  of  clear  screen  routine 
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APPENDIX  T:   LISTING  OF   DOS  FUNC.MAC 


this  is  a  file  of  MS-DOS  2.0  function  macros 


get  time  is  a  macro  which  puts  the  time  in  CX  and  DX 


GET_TIME   MACRO 

MOV     AH,  2CH 
INT     21H 
ENDM 


convert  is  a  macro  which  converts  the  value  parameter  into 
a  number  in  the  base  parameter  system,  and  puts  the 
converted  value  in  the  destination  parameter  location 


CONVERT 

MACRO 

VALUE,  BASE,  DESTINATION 

LOCAL 

TABLE,  START 

JMP 

START 

TABLE 

DB 

"0123456789ABCDEF" 

START: 

MOV 

AL,  VALUE 

XOR 

AH,  AH 

XOR 

BX,  BX 

DIV 

BASE 

MOV 

BL,  AL 

MOV 

AL,  CS : TABLE [BX] 

MOV 

DESTINATION,  AL 

MOV 

BL,  AH 

MOV 

AL,  CS : TABLE [BX] 

MOV 

DESTINATIONS  ,  AL 

ENDM 

display  is  a  macro  which  displays  a  string  located  in 
memory  at  the  location  passed  in  the  parameter  string, 
and  the  string  must  end  with  the  ASCII  code  for  '$',  24H, 


DISPLAY  MACRO 
MOV 
MOV 
INT 
ENDM 

5 

> 


STRING 

DX,  OFFSET  STRING 

AH,  09H 

21H 
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APPENDIX  U:   LISTING  OF   PARM.DEF 


;   file  of  parameter  definitions 

5 

;  i/o  port  address 
IO_PORT  EQU     0D8H 

* 

;horizontal(X) ,  verticai(Y)  start/stop  corners  of  a  box 

? 

X_START  EQU  4 

X_STOP  EQU  58 

Y_START  EQU  6 

Y_STOP   EQU  243 

» 

;color  of  the  box 

COLOR   EQU     3 

> 

;horizontal(X) ,  vertical(Y)  start/stop  corners  of  boxes  that 

;will  serve  as  grid  lines 


» 

GRIDX  START 

EQU 

18 

GRIDX  STOP 

EQU 

19 

GRIDY  START 

EQU 

17 

GRIDY  STOP 

EQU 

19 

color  of  the  grid  lines 


5 


G  COLOR         EQU     4 


> 


;constants  for  loop  counts  and  symbol  location  shifting 


? 


LINE    EQU     1024  ;required  to  shift  one  vertical  line 

;on  the  screen 

length  of  line  in  bytes 


;start  address  of  blue  plane 

; counter  for  loop  J 

jcounter  for  loop  K 

; counter  for  loop  I 

;address  difference  between  color 

; planes 

;horizontal  space  shift 

;vertical  space  shift 
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X  LINE  EQU 

79 

B  PLANE  EQU 

0C000H 

I  COUNT  EQU 

80 

J  COUNT  EQU 

9 

K  COUNT  EQU 

3 

L  COUNT  EQU 

20 

PLANE   EQU 

1000H 

HORZ    EQU 

1 

VERT    EQU 

128 

;size  of  one  character,  nine  scan-lines 


> 


SIZE    EQU     1152 
HITE    EQU     1280 
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APPENDIX  V:   USER'S  MANUAL  FOR  ASSEMBLY  PROGRAMS 

A.  HOW  TO  USE  THE  MACRO-86  PROGRAMS 

Th^  Macro-86  assembly  language  programs  included  in  this 
thesis  have  been  assembled  and  linked.  To  run  any  of  the 
tests  simply  type  the  filename  at  the  system  prompt.  The 
file  READ. ME  on  each  distribution  disk  describes  what 
each  file  is  named  and  what  it  does. 

B.  UNDERSTANDING  THE  CODE 

The  internal  documentation  explains  the  Macro-86  code 
step  by  step.  We  will  not  indulge  in  a  line  by  line 
explanation  as  Appendix  N  does  for  the  BASIC  code.  This 
Appendix  will  discuss  some  of  the  reasons  behind  the  code  in 
the  test  file,  Appendices  0  and  P. 

We  set  up  our  own  segments  for  stack,  data,  and  code 
because  we  are  using  the  EXE  format  rather  than  the  COM 
format.  The  EXE  format  is  necessary  to  provide  direct 
control  of  the  video  random  access  memory  (VRAM)  addresses. 

The  first  entries  in  the  data  segment  are  the  bytes 
which  define  the  test  symbol.  For  these  tests  we  did  not 
establish  complete  symbol  tables  and  perform  table  look-ups, 
as  we  were  interested  in  establishing  simple  timing  bases 
for  efficiency  comparisons  with  the  BASIC  prototype.  SYMBOL 
is  defined  in   binary   form   to   allow   visualisation  of  its 
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constituent  parts.  The  first  byte  on  each  line  of  SYMBOL 
defines  its  blue  plane,  the  second  the  red  and  the  third  the 
green  planes.  This  initialization  may  alter  the  shape  or 
color  of  the  symbol.  The  symbol  may  even  be  constructed  of 
multi-colored  parts.  This  would  not  matter  in  a  monochrome 
system,  of  course.  Since  the  microcomputer  laboratories 
currently  operate  only  monochrome  monitors,  this  test  symbol 
is  defined  in  the  green  plane  only. 

The  shape  of  the  symbol  is  next  defined  separately. 
This  is  necessary  because  a  non-white  symbol  possesses  a 
shape  which  differs  in  each  color  plane.  The  test  symbol  is 
a  prime  example  —  its  shape  in  the  green  plane  matches 
exactly  that  of  SHAPE,  but  it  has  no  shape  in  the  red  and 
blue  planes. 

In  order  to  maintain  the  purity  of  the  background  and 
symbol  colors,  a  space  must  be  cleared  for  the  symbol  in  all 
three  color  planes  (on  a  color  system,  or  a  monochrome 
system  with  the  color  option  installed)  to  all  zeroes.  The 
way  in  which  color  is  generated  (superimposing  three  pixels, 
one  of  each  color  plane)  drives  this  necessity. 

Figure  V.l  illustrates  the   problem.    In  Figure  V.l  the 

background   color   planes   are   represented  in  part  (a),  the 

test  symbol  in  part  (b) .   Parts  (c),   (d)   and   (e)   of   the 

Figure  exhibit  the  results  of   an  OR,  AND  and  XOR  operation, 

respectively,   between   the   color   planes  of  the  symbol  and 

those  of  the  background.   None  of  the  results   produces   the 

correct  result  of  background  and  symbol,  shown  in  part  (f). 
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BLUE 


COLOR      PLANE 
RED 


GREEN 


1 

1 

1 

1 

1 

1 

0 

0 

0 

0 

0 

0 

(a)  Background 


0 

1 

1 

0 

0 

0 

0 

1 

1 

0 

0 

0 

(b)  Symbol 


0 

1 

1 

0 

0 

0 

0 

0 

0 

0 

0 

0 

(c)  Background  AND  Symbol 
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1 

1 

1 

1 

1 

0 

1 

1 

0 

0 

0 

(d)  Background  OR  Symbol 


1 

0 

0 

1 

1 

1 

0 

1 

1 

0 

0 

0 

(e)  Background  XOR  Symbol 
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1 
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1 

1 

0 

0 

0 

1 

1 

1 

1 

1 

1 

0 

0 

0 
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0 

0 

0 

1 
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1 
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1 
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1 

1 

1 

(f)  Desired  Results 


Figure  V.l   Results  of  Operating  with  Symbol  Directly 


132 


Figure  V.2  illustrates  the  solution.  The  background 
planes  are  in  part  (a),  as  before.  Part  (b)  is  the  shape  of 
the  symbol  inverted  and  stored  in  each  plane,  creating  a 
mask  which  is  ANDed  with  the  background  to  produce  part  (c). 
This  mask  is  created  by  the  SHAPE  stored  in  data.  By 
performing  the  AND  operation  of  the  background  and  the 
inverse  of  the  symbol  shape,  a  screen  area  of  background 
with  black  where  the  symbol  will  appear  is  created  (c). 
Part  (d)  is  the  actual  symbol,  which  will  appear  differently 
in  each  color  plane  unless  it  is  all  white.  When  (c)  and 
(d)  are  OR'd  together  the  correct  background/symbol  colors 
appear  in  part  (e),  matching  part  (f). 

The  PARM.DEF  file  which  is  included  next  is  a  file  of 
defined  constants.  During  the  development  process  the 
collection  of  all  constants  in  one  separate  file  allowed 
simpler  experimentation  and  debugging. 

Another  file,  DOS_FUNC.MAC,  is  included  after  PARM.DEF. 
This  is  a  file  of  Microsoft  Disk  Operating  System  Function 
Macros  (hence  the  name  and  the  extension).  These  files  may 
be  found  at  the  end  of  chapter  four  in  Reference  4.  They 
are  macros  that  perform  some  of  the  basic  MS-DOS  functions. 

The  first  three  lines  of  the  code  segment  (after  the 
ASSUME  statement)  initialize  the  stack  segment  register  and 
the  stack  pointer.  The  AX  register  is  used  as  an  inter- 
mediary, because  the  segment  registers  should  never  be 
written  to  directly. 
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(b)  Symbol  Shape 
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(c)  Background  AND  Inverted  Shape 
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(d)  Symbol 
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(e)  Symbol  OR'd  with  (c) 
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(f)  Desired  Results 


Figure  V.2   Results  of  Operating  with  Shape  and  Symbol 
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After  that,  three  lines  prepare  for  a  graceful  exit.  If 
a  Macro-86  program  is  ended  with  a  far  return,  and  the  stack 
has  had  the  proper  addresses  saved  on  it  for  this  type  of 
exit,  a  simple  return  to  the  operating  system  is  effected. 
The  preparation  of  the  stack  involves  saving  the  DS 
register,  and  an  offset  of  zero.  Having  saved  the  DS 
register  for  the  return,  the  next  two  lines  initialize  it  to 
access  our  own  data  segment. 

It  is  not  absolutely  necessary  to  include  the  next  three 
lines  of  code.  They  read  and  save  the  input/output  port 
status.  This  is  our  standard  programming  practice  of 
utilizing  the  stack  to  save  values  (such  as  status 
registers)  that  our  program  modifies,  in  order  that  they  may 
be  properly  restored  upon  completion  of  our  program's 
execution. 

After  clearing  the  screen,  the  registers  involved  in 
creating  a  window  on  the  screen  are  loaded  with  the 
necessary  values.  The  header  at  the  top  of  the  BOX. SUB  file 
describes  what  values  are  needed,  and  how  they  are  used. 

Next  we  call  the  timer  routine,  in  order  to  measure  the 
time  efficiency  of  the  routine  which  draws  the  symbols.  The 
input/output  port  is  prepared  by  the  next  few  lines  of  code 
to  allow  our  symbol-drawing  operation. 

The  next  six  lines  of  code,  from  SUB  BP,  BP  through  NEG 
BP,  make  preparation  for  entering  our  outer  loop.  The  base 
pointer    (BP)    register    is   initialized   to   a   negative 
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value  so  that  the  outer  loop  may  begin  each  repetition  by 
incrementing  a  value  equal  to  LINE  and  still  begin  the  first 
iteration  at  a  value  of  zero.  The  value  of  zero  is 
equivalent  to  the  upper  left-hand  corner  of  the  screen. 

Labels  identify  the  statements  which  make  up  the  tops  of 
each  of  the  iterative  loops.  The  internal  documentation 
identifies  the  initialization  required  for  each  loop.  The 
order  of  steps  could  be  modified  to  save  a  few  operations 
involving  the  accumulator  (AX).  We  elected  to  write  the 
code  this  way  for  clarity  of  purpose. 

The  inner  loop,  LOOP_K,  first  performs  the  AND 
operations  discussed  earlier,  to  clear  a  space  for  the 
symbol.  Then  the  OR  operation  described  is  performed,  to 
write  the  appropriate  plane  of  the  symbol  into  the  proper 
color  plane.  The  loop  is  repeated  for  each  color  plane, 
making  use  of  the  ES  register  to  point  to  the  proper 
location  in  VRAM. 

The  third  loop,  LOOP_J,  repeats  the  inner  loop  for  each 
scan  line  of  the  symbol.  LOOP_I  fills  each  line  with 
symbols,  and  LOOP_L  fills  the  specified  number  of  lines. 

C.   MODIFYING  THE  CODE 

The  easiest  changes  are  to  the  symbol.  Its  shape  is 
modified  by  changing  the  binary  definition  of  it  within  the 
data  segment  of  the  driver  program.  Corresponding  changes 
should  be  made   to   the   bytes   defining   SHAPE   in  the  same 
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program.  Defining  the  symbol  in  different  color  planes 
and/or  combinations  of  color  planes  modifies  its  color.  If 
the  binary  representation  differs  from  color  plane  to  color 
plane  a  multi-colored  symbol  is  possible.  However,  the 
shape  is  singly  defined  with  the  current  program  version, 
and  the  colors  desired  may  not  be  the  ones  displayed.  The 
actual  symbol  display  will  depend  upon  background.  All 
other  simple  changes,  those  not  affecting  the  program  logic 
but  just  modifying  the  display,  are  made  by  altering  the 
values  of  the  constants  in  the  PARM.DEF  file.  Those  are 
discussed  in  the  next  section. 

D.   CONSTANTS 

The  constants  defined  in  the  PARM.DEF  file  (Appendix  U) 
determine  the  display  characteristics.  They  are  listed  in 
tabular  form  below,  along  with  their  use. 


NAME 


10  PORT 


X  START 


X  STOP 


Y  START 


Y  STOP 


COLOR 


PURPOSE 

port  address  for  Zenith  input/ 
output  port  status  register 

x  coordinate  (in  pixels)  of  left 
side  of  window 

x  coordinate  (in  pixels)  of  right 
side  of  window 

y  coordinate  (in  pixels)  of  top 
of  window 

y  coordinate  (in  pixels)  of  bottom 
of  window 

color  of  window 
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NAME 


PURPOSE 


GRIDX  START 


GRIDX  STOP 


GRIDY  START 


GRIDY  STOP 


G  COLOR 


x  coordinate  (in  pixels)  of 
left  of  vertical  reference  grid 

x  coordinate  (in  pixels)  of 
right  of  vertical  reference  grid 

y  coordinate  (in  pixels)  of 

f'u  g2  r,,..lSl..c...  yd2dyd^'d  ,ynl 

y  coordinate  (in  pixels)  of 

bottom  of  horizontal  reference  grid 

color  of  reference  grid 


LINE 

X_LINE 

B_PLANE 

I_COUNT 

J_COUNT 
K_COUNT 
L_COUNT 

PLANE 

HORZ 

VERT 


SIZE 

HITE 


address  modification  required  to 
shift  down  one  line  on  the  screen 

number  of  right-most  byte  on  one 
character  line  of  the  display 

address  of  blue  color  plane  in 
VRAM 

number  of  symbols  to  write 
horizontally 

number  of  scan  lines  per  symbol 

number  of  color  planes 

number  of  lines  to  fill  with 
symbols 

hex  difference  between  color 
plane  addresses 

number  of  bytes  to  shift  right 
while  filling  symbols  in 

difference  in  address  between 
top  scan-line  address  and 
bottom  scan-line  address  of 
the  same  symbol  position  on 
the  screen 

not  used 

not  used 
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